Re: Overhauling GUCS

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(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD