> 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 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
