Re: Seq scans roadmap

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?

I'm not sure. Needs testing. Assuming the scan leaves behind a cache 
trail in the OS cache as well, it might not be that bad if a scan 
joining the party starts a little bit behind.

> 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).

Keep in mind that processing a 32K page takes longer than processing an 
8K page.

But we'll see..

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