From: | "Craig A(dot) James" <cjames(at)modgraph-usa(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | robin(dot)c(dot)smith(at)bt(dot)com, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Forcing using index instead of sequential scan? |
Date: | 2006-07-22 17:26:53 |
Message-ID: | 44C25FDD.8070003@modgraph-usa.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Gregory Stark | 2006-07-22 23:15:31 | Re: Forcing using index instead of sequential scan? |
Previous Message | Tom Lane | 2006-07-22 17:03:58 | Re: Bad Planner Statistics for Uneven distribution. |