Re: Overhauling GUCS - Mailing list pgsql-hackers

From Greg Smith
Subject Re: Overhauling GUCS
Date
Msg-id Pine.GSO.4.64.0806041720520.26357@westnet.com
Whole thread Raw
In response to Re: Overhauling GUCS  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Overhauling GUCS  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, 4 Jun 2008, Tom Lane wrote:

> The real problem we need to solve is how to allow newbies to have the
> system auto-configured to something that more or less solves their
> problems.  Putting the config settings in XML does not accomplish that,
> and neither does putting them inside the database.

The subtle issue here is that what makes sense for the database 
configuration changes over time; there's not just one initial generation 
and you're done.  postgresql.conf files can end up moving from one machine 
to another for example.  I think something that doesn't recognize that 
reality and move toward a "tune-up" capability as well as initial 
generation wouldn't be as useful, and that's where putting the settings 
inside the database helps so much.

Also, there's a certain elegance to having a optimization tool that works 
again either a new installation or an existing one.  I personally have 
zero interest in a one-shot config generator.  It just doesn't solve the 
problems I see in the field.  Performance starts out just fine even with 
the default settings when people first start, and then goes to hell after 
the system has been running for a while (and possibly moved to another 
machine).  By that point nobody wants to mess with their configuration 
file unless it's one simple change at a time.

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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Overhauling GUCS
Next
From: Greg Smith
Date:
Subject: Re: rfc: add pg_dump options to dump output