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
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
