Horton

Re: Seq scans roadmap

Decibel! <decibel@decibel.org>

View thread View on postgr.es
From: "Jim C. Nasby" <decibel@decibel.org>
To: Jeff Davis <pgsql@j-davis.com>
Cc: Heikki Linnakangas <heikki@enterprisedb.com>, Luke Lonergan <LLonergan@greenplum.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Simon Riggs <simon@enterprisedb.com>, Zeugswetter Andreas ADI SD <ZeugswetterA@spardat.at>, "CK.Tan" <cktan@greenplum.com>
Date: 2007-05-15T22:34:11Z
Lists: pgsql-hackers 
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?
-- 
Jim Nasby                                      decibel@decibel.org
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)