On Tue, Jan 29, 2008 at 10:40:40AM +0100, Zeugswetter Andreas ADI SD wrote: > > > It's a good point that we don't want pg_dump to screw up the cluster > > order, but that's the only use case I've seen this far for disabling > > sync scans. Even that wouldn't matter much if our estimate for > > "clusteredness" didn't get screwed up by a table that looks > > like this: > > "5 6 7 8 9 1 2 3 4" > > I do think the guc to turn it off is useful, only I don't understand the > reasoning that pg_dump needs it to maintain the basic clustered > property. > > Sorry, but I don't grok this at all. > Why the heck would we care if we have 2 parts of the table perfectly > clustered, > because we started in the middle ? Surely our stats collector should > recognize > such a table as perfectly clustered. Does it not ? We are talking about > one > breakage in the readahead logic here, this should only bring the > clustered property > from 100% to some 99.99% depending on table size vs readahead window. > > Andreas >
Andreas, I agree with your logic. If the process that PostgreSQL uses to determine how clustered a table is that breaks with such a layout, we may need to see what should be changed to make it work. Having had pg_dump cause a database to grind to a halt, I would definitely like the option of using the synchronized scans even for clustered tables. Ken ---------------------------(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