The real issue here is caching across successive queries, an effect that
Postgres doesn't deal with very well at the moment. If you run these
queries from a standing start (freshly booted machine) you'll likely
find that the indexscan plan is indeed slower than the seqscan/hash
plan, just like the planner thinks.
Here's a little trick I learned to speed up this test.
find / -type f -exec grep foobar {} \;
This causes massive file-system activity and flushes all files that the kernel
has cached. If you run this between each Postgres test (let it run for a
couple minutes), it gives you an apples-to-apples comparison between successive
benchmarks, and eliminates the effects of caching.
If you run this as a regular user (NOT super-user or 'postgres'), you won't
have permission to access your Postgres files, so you're guaranteed they'll be
flushed from the cache.
Craig
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
