Re: Overhauling GUCS

* Greg Smith <gsmith(at)gregsmith(dot)com> [080605 15:17]:
> On Thu, 5 Jun 2008, Alvaro Herrera wrote:
>
> >I must say that I am confused by this thread. What's the discussed GUC
> >overhaul?
>
> http://wiki.postgresql.org/wiki/GUCS_Overhaul
>
> I drop that URL in every other message in hopes that people might start
> commenting on it directly if they see it enough; the fact that you're
> confused says I may need to keep that up :(

I've read it. A couple times now. And I like lots of it.

> >(1) Add a lot more comments to each setting
> >(2) Add documentation links to each setting
> >(3) Move more frequently used settings to the top of the file
> >(4) Ship different sample config files
> >(5) Create an expert system to suggest tuning
> >(6) Other random ideas (XML, settings in database, others?)

> (3) (4) (5) and (6) were off-topic diversions.

But, right from the above mentioned page:

*Goals*

By shifting from a model where postgresql.conf is document-formatted
and hand-edited to one where it's machine generated, it becomes vastly
easier to write simple utilities to manage these settings. Right now,
the big "obstacle" to things like SET PERSISTENT is "how to we
preserve the hand-edited comments in the file" -- and the answer is we
don't.

This little goal leads to:

* By having a generated postgresql.conf and an easy way to generate
it, writing autoconfiguration scripts (as well as shortcuts like SET
PERSISTENT) become vastly easier.

And later:

There needs to be a way to modify the underlying settings and save
that into a new machine-generated postgresql.conf file. Is
implementing SET PERSISTENT sufficient for that?

I think that these parts, seemingly "snuck into" the GUC overhaul
proposal is what people like me a wary of. 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.

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.

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

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

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

--
Aidan Van Dyk Create like a god,
aidan(at)highrise(dot)ca command like a king,
http://www.highrise.ca/ work like a slave.