> 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

Sorry, but I don't grok this at all.
Why the heck would we care if we have 2 parts of the table perfectly
because we started in the middle ? Surely our stats collector should
such a table as perfectly clustered. Does it not ? We are talking about
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.


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply via email to