Tom Lane wrote: > Right. Multiple seqscans that are anywhere near reading the same block > of a table will tend to self-synchronize. There is a patch under > consideration for 8.3 that helps this along by making seqscans run > "circularly" --- that is, not always from block 0 to block N, but from > block M to N and then 0 to M-1, where the start point M can be chosen > by looking to see where any other concurrent seqscan is presently > reading. Once you've got a reasonable start point, you don't have to do > anything else. > > regards, tom lane Interesting concept (as expected from you guys). Would that imply that the sequential scan of one connection could place data into the disk cache that another parallel seq scan would need soon? Would that speed up parallel seq scans? Or am I being optimistic here. Regards, -- Alban Hertroys alban@xxxxxxxxxxxxxxxxx magproductions b.v. T: ++31(0)534346874 F: ++31(0)534346876 M: I: www.magproductions.nl A: Postbus 416 7500 AK Enschede // Integrate Your World //
