Re: Overhauling GUCS - Mailing list pgsql-hackers

* Greg Smith <gsmith@gregsmith.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
thingslike 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
asshortcuts 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
nevertouch.  
 
  3. GUCS lists are kept in 3 different places (guc.c, postgresql.conf,     and settings.sgml), which are only synched
witheach other manually.  
 
  4. We don't seem to be getting any closer to autotuning. 


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