Subject: Re: Overhauling GUCS
From: Simon Riggs <simon@2ndquadrant.com>
To: "Jignesh K. Shah" <J.K.Shah@Sun.COM>
Cc: Josh Berkus <josh@agliodbs.com>, pgsql-hackers@postgresql.org
In-Reply-To: <484418D9.5040608@sun.com>
References: <48409D1E.3070208@agliodbs.com>
	<1212219274.4120.191.camel@ebony.site>  <484418D9.5040608@sun.com>
Content-Type: text/plain
Date: Mon, 02 Jun 2008 17:29:17 +0100
Message-Id: <1212424157.4120.371.camel@ebony.site>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit


On Mon, 2008-06-02 at 11:59 -0400, Jignesh K. Shah wrote:
> 
> Simon Riggs wrote:
> >
> > Some other problems I see with GUCs
> >
> > * It's not possible to set one parameter depending upon the setting of
> > another.
> >   
> 
> To me this is more critical.. Most people I have seen will increase one 
> or few but not all parameters related to memory which can result in loss 
> of performance and productivity in figuring out.
> 
> What happened to AvailRAM setting and base all memory gucs on that.  
> Ideally PostgreSQL should only create one big memory pool and allow all 
> other variables to change runtime via dba or some tuner process or 
> customized application as long as total is less than the allocated 
> shared_memory and local_memory settings. (This will also reduce the need 
> of restarting Postgres if a value needs to be changed)

Agreed.

Right now, we can't even do that in code, let alone in config file.

If we had a smart_memory_config = on then we'd be able to say in the
backend:
	if (smart_memory_config)
	{
		other_thing = 0.1 * Nbuffers;
	}

but the GUCs are evaluated in alphabetical order, without any way of
putting dependencies between them. So they are notionally orthogonal.   

-- 
 Simon Riggs           www.2ndQuadrant.com
 PostgreSQL Training, Services and Support