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