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 [EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
