Re: Seq scans roadmap

I think the analysis on syncscan needs to take the external I/O cache into
account. I believe it is not necessary or desirable to keep the scans in
lock step within the PG bufcache.

The main benefit of a sync scan will be the ability to start the scan where
other scans have already filled the I/O cache with useful blocks. This will
require some knowledge of the size of the I/O cache by the syncscan logic,
but that's where the largest amount of I/O cache memory (by far) is located.

- Luke

On 5/15/07 3:34 PM, "Jim C. Nasby" <decibel(at)decibel(dot)org> wrote:

> On Tue, May 15, 2007 at 10:25:35AM -0700, Jeff Davis wrote:
>> On Tue, 2007-05-15 at 10:42 +0100, Heikki Linnakangas wrote:
>>> Luke Lonergan wrote:
>>>> 32 buffers = 1MB with 32KB blocksize, which spoils the CPU L2 cache
>>>> effect.
>>>>
>>>> How about using 256/blocksize?
>>>
>>> Sounds reasonable. We need to check the effect on the synchronized
>>> scans, though.
>>>
>>
>> I am a little worried that there will be greater differences in position
>> as the number of scans increase. If we have only 8 buffers and several
>> scans progressing, will they all be able to stay within a few buffers of
>> eachother at any given time?
>>
>> Also, with 8 buffers, that means each scan must report every 4 pages at
>> most (and maybe every page), which increases lock contention (the new
>> design Heikki and I discussed requires a lock every time a backend
>> reports its position).
>
> Given that spoiling the L2 cache is a trivial cost compared to extra
> physical IO, ISTM we should go with a largish ring for sync scans. What
> do you think would be the ideal size? 32 buffers?