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
