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(at)j-davis(dot)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