Horton

Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable

Zeugswetter Andreas OSB sIT <andreas.zeugswetter@s-itsolutions.at>

View thread View on postgr.es
From: "Zeugswetter Andreas ADI SD" <Andreas.Zeugswetter@s-itsolutions.at>
To: "Heikki Linnakangas" <heikki@enterprisedb.com>, "Simon Riggs" <simon@2ndquadrant.com>
Cc: "Tom Lane" <tgl@sss.pgh.pa.us>, "Neil Conway" <neilc@samurai.com>, "Gregory Stark" <stark@enterprisedb.com>, "Jonah H. Harris" <jonah.harris@gmail.com>, <pgsql-hackers@postgreSQL.org>
Date: 2008-01-29T09:40:40Z
Lists: pgsql-hackers 
> 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