Re: Overhauling GUCS - Mailing list pgsql-hackers

"Greg Smith" <gsmith@gregsmith.com> writes:

> On Mon, 18 Aug 2008, Michael Nacos wrote:
>
>> Having done a SELECT * FROM pg_settings, all the information you need seems
>> to be there...
>
> See http://archives.postgresql.org/pgsql-hackers/2008-06/msg00209.php You sound
> like you're at rung 2 on the tool author ladder I describe there, still
> thinking about the fun part of tuning but not yet aware of the annoying
> postgresql.conf management issues that show up in the field that motivate many
> of the GUCS changes suggested.  Coping with user and system-generated comments
> is one difficult part that people normally don't consider, 

Because coping with free-form user-edited text is a losing game. People don't
consider it because it's a dead-end. Instead you have one file for user-edited
configuration and a separate file for computer generated configuration. You
never try to automatically edit a user-edited file -- that way lies madness.

> dealing with bad settings the server won't start with is another.

A tuning interface can't be turing complete and detect all possible
misconfigurations. To do that it would have to be as complex as the server.

In any case worrying about things like this before you have a tuning interface
that can do the basics is putting the cart before the horse.

>> As soon as there is a tuning strategy published, a number of tools will
>> certainly follow.
>
> Josh Berkus published one in 2005 and zero such tools have been produced since
> then, even though it looked to him then (like it does to you now and like it
> did to me once) that such a tool would easily follow:
> http://pgfoundry.org/docman/?group_id=1000106

The entire target market for such a thing is DBAs stuck on hosted databases
which don't have shell access to their machines. Perhaps the overlap between
that and the people who can write a server-side module which dumps out a
config file according to some rules is just too small?

I do think you and others make it less likely every time you throw up big
insoluble problems like above though. As a consequence every proposal has
started with big overly-complex solutions trying to solve all these incidental
issues which never go anywhere instead of simple solutions which directly
tackle the main problem.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production
Tuning