Date: Mon, 02 Jun 2008 11:59:21 -0400
From: "Jignesh K. Shah" <J.K.Shah@Sun.COM>
Subject: Re: Overhauling GUCS
In-reply-to: <1212219274.4120.191.camel@ebony.site>
To: Simon Riggs <simon@2ndquadrant.com>
Cc: Josh Berkus <josh@agliodbs.com>, pgsql-hackers@postgresql.org
Message-id: <484418D9.5040608@sun.com>
Organization: Sun Microsystems
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
References: <48409D1E.3070208@agliodbs.com>
	<1212219274.4120.191.camel@ebony.site>
User-Agent: Thunderbird 2.0.0.9 (X11/20080119)


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)


-Jignesh

> * It's always unclear which GUCs can be changed, and when. That is much
> more infrequently understood than the meaning of them.
>
> * We should rename effective_cache_size to something that doesn't sound
> like it does what shared_buffers does
>
> * There is no config verification utility, so if you make a change and
> then try to restart and it won't, you are in trouble.
>
>