From: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Luke Lonergan <LLonergan(at)greenplum(dot)com>, Grzegorz Jaskiewicz <gj(at)pointblue(dot)com(dot)pl>, PGSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Doug Rady <drady(at)greenplum(dot)com>, Sherry Moore <sherry(dot)moore(at)sun(dot)com> |
Subject: | Re: Bug: Buffer cache is not scan resistant |
Date: | 2007-03-05 21:03:48 |
Message-ID: | 45EC85B4.2060009@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Kirkwood | 2007-03-05 21:28:21 | Re: Bug: Buffer cache is not scan resistant |
Previous Message | Tom Lane | 2007-03-05 21:03:10 | Re: Bug: Buffer cache is not scan resistant |