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" <[EMAIL PROTECTED]> 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? ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
