Re: Bug: Buffer cache is not scan resistant

Jeff Davis wrote:
> On Mon, 2007-03-05 at 15:30 -0500, Tom Lane wrote:
>> Jeff Davis <pgsql@j-davis.com> writes:
>>> Absolutely. I've got a parameter in my patch "sync_scan_offset" that
>>> starts a seq scan N pages before the position of the last seq scan
>>> running on that table (or a current seq scan if there's still a scan
>>> going). 
>> Strikes me that expressing that parameter as a percentage of
>> shared_buffers might make it less in need of manual tuning ...
>>
> 
> The original patch was a percentage of effective_cache_size, because in
> theory it may be helpful to have this parameter larger than shared
> buffers. Synchronized Scannning can take advantage of OS buffer cache as
> well.
> 
> Someone convinced me to change it to be an independent variable.
> 
> I don't have a strong opinion, but now I have three different opinions:
> (1) Independent parameter
> (2) Percentage of shared_buffers
> (3) Percentage of effective_cache_size

Another approach I proposed back in December is to not have a variable 
like that at all, but scan the buffer cache for pages belonging to the 
table you're scanning to initialize the scan. Scanning all the 
BufferDescs is a fairly CPU and lock heavy operation, but it might be ok 
given that we're talking about large I/O bound sequential scans. It 
would require no DBA tuning and would work more robustly in varying 
conditions. I'm not sure where you would continue after scanning the 
in-cache pages. At the highest in-cache block number, perhaps.

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