From: Craig A. James <cjames@modgraph-usa.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: robin.c.smith@bt.com
Cc: pgsql-performance@postgresql.org
Subject: Re: Forcing using index instead of sequential scan?
Date: Sat, 22 Jul 2006 10:26:53 -0700
Message-ID: <44C25FDD.8070003@modgraph-usa.com> (raw)
In-Reply-To: <26827.1153585341@sss.pgh.pa.us>
References: <D012B9600FFB984AB18C0D53C475A4A081F51B@E03MVZ3-UKDY.domain1.systemhost.net>
<26827.1153585341@sss.pgh.pa.us>
> 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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: cjames@modgraph-usa.com, tgl@sss.pgh.pa.us, robin.c.smith@bt.com
Subject: Re: Forcing using index instead of sequential scan?
In-Reply-To: <44C25FDD.8070003@modgraph-usa.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox