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

Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: 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-28 22:39:41
Message-ID: 1201559981.4257.799.camel@ebony.site (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
On Mon, 2008-01-28 at 16:21 -0500, Tom Lane wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> > Rather than having a boolean GUC, we should have a number and make the
> > parameter "synchronised_scan_threshold".
> 
> This would open up a can of worms I'd prefer not to touch, having to do
> with whether the buffer-access-strategy behavior should track that or
> not.  As the note in heapam.c says,
> 
>      * If the table is large relative to NBuffers, use a bulk-read access
>      * strategy and enable synchronized scanning (see syncscan.c).  Although
>      * the thresholds for these features could be different, we make them the
>      * same so that there are only two behaviors to tune rather than four.
> 
> It's a bit late in the cycle to be revisiting that choice.  Now we do
> already have three behaviors to worry about (BAS on and syncscan off)
> but throwing in a randomly settable knob will take it back to four,
> and we have no idea how that fourth case will behave.  The other tack we
> could take (having the one GUC variable control both thresholds) is
> not good since it will result in pg_dump trashing the buffer cache.

OK, good points. 

I'm still concerned that the thresholds gets higher as we increase
shared_buffers. We may be removing performance features as fast as we
gain performance when we set shared_buffers higher.

Might we agree that the threshold should be fixed at 8MB, rather than
varying upwards as we try to tune? 

The objective of having a tuning hook would have been simply to
normalise the effects of increasing shared_buffers anyway, so fixing it
would solve the problem I see.

(8MB is the default, based upon 25% of 32MB).

-- 
  Simon Riggs
  2ndQuadrant  http://www.2ndQuadrant.com 


In response to

Responses

pgsql-hackers by date

Next:From: Jeff DavisDate: 2008-01-28 22:44:52
Subject: Re: CLUSTER and synchronized scans and pg_dump et al
Previous:From: Jeff DavisDate: 2008-01-28 22:38:50
Subject: Re: CLUSTER and synchronized scans and pg_dump et al

pgsql-patches by date

Next:From: Jeff DavisDate: 2008-01-28 22:58:13
Subject: Re: Proposed patch: synchronized_scanning GUC variable
Previous:From: Andrew DunstanDate: 2008-01-28 21:34:18
Subject: Re: WIP: plpgsql source code obfuscation

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