Isn't it more fair to just flush the cache before doing each of the
queries? In real-life, you'll also have disk caching... Flushing the
buffer pool is easy, just restart PostgreSQL (or perhaps there is a
admin command for it too?). Flushing the OS-disk cache is obviously
OS-dependent, for linux its trivial: http://linux-mm.org/Drop_Caches
Best regards,
Arjen
On 26-8-2010 12:32 Willy-Bas Loos wrote:
Hi,
I have a colleague that is convinced that the website is faster if
enable_seqscan is turned OFF.
I'm convinced of the opposite (better to leave it ON), but i would like
to show it, prove it to him.
Now the first query we tried, would do a bitmap heap scan instead of a
seqscan when the latter were disabled, to exclude about 50% of the
records (18K of 37K records).
The bitmap heap scan is 3% faster, so that didn't really plea my case.
The thing is that by the time we tried it, the data had been cached, so
there is no penalty for the use of the index (HDD retention on random
access). So it's logical that the index lookup is faster, it looks up
less records.
Now i'm looking for a way to turn off the caching, so that we'll have a
fair test.
It makes no sense to me to set shared_buffers really low. Any tips?
Cheers,
WBL
--
"Patriotism is the conviction that your country is superior to all
others because you were born in it." -- George Bernard Shaw
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
