Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable

From: Kenneth Marshall <ktm(at)rice(dot)edu>
To: Zeugswetter Andreas ADI SD <Andreas(dot)Zeugswetter(at)s-itsolutions(dot)at>
Cc: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Neil Conway <neilc(at)samurai(dot)com>, Gregory Stark <stark(at)enterprisedb(dot)com>, "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable
Date: 2008-01-29 13:40:38
Message-ID: 20080129134038.GI4201@it.is.rice.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-01-29 15:10:22 Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable
Previous Message Euler Taveira de Oliveira 2008-01-29 13:31:01 Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable

Browse pgsql-patches by date

  From Date Subject
Next Message Peter Eisentraut 2008-01-29 14:19:39 Re: WIP: plpgsql source code obfuscation
Previous Message Euler Taveira de Oliveira 2008-01-29 13:31:01 Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable