Re: Overhauling GUCS - Mailing list pgsql-hackers

On Thu, 5 Jun 2008, Aidan Van Dyk wrote:

> People like me don't want to have postgresql.conf be *only* a 
> machine-generated file, which I am not allowed to edit anymore because 
> next DBA doing a "SET PERSISTANT" type of command is going to cause 
> postgres to write out something else, over-writing my carefully 
> documented reason for some particular setting.

This is why there's the emphasis on preserving comments as they pass into 
the GUC structure and back to an output file.  This is one of the 
implementation details I haven't fully made up my mind on:  how to clearly 
label user comments in the postgresql.conf to distinguish them from 
verbose ones added to the file.  I have no intention of letting manual 
user edits go away; what I'm trying to do here (and this part is much more 
me than Josh) is make them more uniform such that they can co-exist with 
machine edits without either stomping on the other.  Right now doing that 
is difficult, because it's impossible to tell the default comments from 
the ones the users added and the current comment structure bleeds onto the 
same lines as the settings.

> But the big issue I have (not that it really matters, because I'm not
> one of the ones working on it, so I please don't take this as me telling
> anyone what they can or can't do) is that that goal doesn't solve any of
> the listed problems stated in the proposal
>   1.  Most people have no idea how to set these.

Making it much easier to build recommendation tools is how this helps 
here.

>   2. The current postgresql.conf file is a huge mess of 194 options,
>      the vast majority of which most users will never touch.

The proposed pg_generate_conf tool includes options to spit out a basic 
configuration file instead of the complete one.

>   3. GUCS lists are kept in 3 different places (guc.c, postgresql.conf,
>      and settings.sgml), which are only synched with each other manually.

The proposal throws away having a separate postgresql.conf file, so that 
reduces it from 3 places to 2.  That's moving in the right direction

>   4. We don't seem to be getting any closer to autotuning.

If you try to build a tuning tool, these areas end up being the 
unnecessarily hard parts.

Thanks for the comments on the proposal.  I'm only bothering to respond to 
messages like yours now, am deleting all of the continuing attemps to 
divert the discussion over to parameter tuning details or expanding the 
scope here.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD