Skip site navigation (1) Skip section navigation (2)

Re: [PATCHES] Proposed patch: synchronized_scanningGUCvariable

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_scanningGUCvariable
Date: 2008-01-29 13:40:38
Message-ID: 20080129134038.GI4201@it.is.rice.edu (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-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

pgsql-hackers by date

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

pgsql-patches by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group