Re: Bug: Buffer cache is not scan resistant - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Bug: Buffer cache is not scan resistant
Date
Msg-id 45EDB747.90003@enterprisedb.com
Whole thread Raw
In response to Re: Bug: Buffer cache is not scan resistant  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Bug: Buffer cache is not scan resistant  (Jeff Davis <pgsql@j-davis.com>)
List pgsql-hackers
Tom Lane wrote:
> Jeff Davis <pgsql@j-davis.com> writes:
>> If I were to implement this idea, I think Heikki's bitmap of pages
>> already read is the way to go.
> 
> I think that's a good way to guarantee that you'll not finish in time
> for 8.3.  Heikki's idea is just at the handwaving stage at this point,
> and I'm not even convinced that it will offer any win.  (Pages in
> cache will be picked up by a seqscan already.)

The scenario that I'm worried about is that you have a table that's 
slightly larger than RAM. If you issue many seqscans on that table, one 
at a time, every seqscan will have to read the whole table from disk, 
even though say 90% of it is in cache when the scan starts.

This can be alleviated by using a large enough sync_scan_offset, but a 
single setting like that is tricky to tune, especially if your workload 
is not completely constant. Tune it too low, and you don't get much 
benefit, tune it too high and your scans diverge and you lose all benefit.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Teodor Sigaev
Date:
Subject: Re: GIST and TOAST
Next
From: Josh Berkus
Date:
Subject: Re: Auto creation of Partitions