There have been many heated arguments over this issue in the PG hacker's list, with the person who works on the optimizer being somewhat stubbornly hard to convince that the kind of exponential decay in execution time one sees with queries such as yours means that in most real-life questions it's better to err on the side of using an index than not. The penalty of being wrong in that direction generally isn't nearly as bad as being wrong in the direction of nested sequential scans. And of course the existence of an index might be considered a hint on the part of the datamodel designer that the index is expected to be used whenever it makes sense to do so.
But, as I say, the optimizer guy has stubbornly resisted efforts to change his opinion.
You can turn off sequential scans before the query is executed via a set command of some sort, check the docs. This will force the use of the index.
