Jim, On 9/22/06 7:01 AM, "Jim C. Nasby" <jim@xxxxxxxxx> wrote: > There's been talk of adding code that would have a seqscan detect if > another seqscan is happening on the table at the same time, and if it > is, to start it's seqscan wherever the other seqscan is currently > running. That would probably ensure that we weren't reading from the > table in 2 different places, even if we weren't caching. Right, aka "SyncScan" The optimization you point out that we miss when bypassing cache is a pretty unlikely event in real world apps, though it makes poorly designed benchmarks go really fast. It's much more likely that the second seqscan will start after the block cache is exhausted, which will cause actuator thrashing (depending on the readahead that the OS uses). SyncScan fixes that. - Luke
