From: Tom Lane <tgl@sss.pgh.pa.us>
To: Bruce Momjian <bruce@momjian.us>
Cc: Andrew Dunstan <andrew@dunslane.net>
Cc: Greg Smith <gsmith@gregsmith.com>
Cc: Andreas Pflug <pgadmin@pse-consulting.de>
Cc: Decibel! <decibel@decibel.org>
Cc: Peter Eisentraut <peter_e@gmx.net>
Cc: pgsql-hackers@postgresql.org, Josh Berkus <josh@agliodbs.com>
Subject: Re: Overhauling GUCS
Date: Wed, 11 Jun 2008 20:56:24 -0400
Message-ID: <25534.1213232184@sss.pgh.pa.us> (raw)
In-Reply-To: <200806112340.m5BNea602628@momjian.us>
References: <200806112340.m5BNea602628@momjian.us>
Bruce Momjian <bruce@momjian.us> writes:
> Tom Lane wrote:
>> Bruce Momjian <bruce@momjian.us> writes:
>>> The second idea is the idea of having one parameter depend on another.
>> We have tried to do that in the past, and it didn't work well *at all*.
> We have? When?
Just a couple months ago we had to give up enforcing an
interrelationship between NBuffers and MaxConnections, because it got
too complicated and un-explainable. I seem to recall some other
interactions in the distant past, but a quick look through the CVS logs
didn't find any smoking guns.
>> The idea has a fundamental logical flaw, which is that it's not clear
>> which parameter wins if the user changes both.
> Yes, you could get into problems by having variable dependency loops,
Who said anything about loops? What I am talking about is what happens
during
set memory_usage = X; // implicitly sets work_mem = X/100, say
set work_mem = Y;
set memory_usage = Z;
What is work_mem now, and what's your excuse for saying so, and how
will you document the behavior so that users can understand it?
(Just to make things interesting, assume that some of the above SETs
happen via changing postgresql.conf rather than directly.)
If the objective is to make configuration easier to understand,
I don't believe that behind-the-scenes changes of configuration values
will advance that goal.
> but I see no way to easily improve configuration without it.
The higher-level concepts should be things that a configuration wizard
works with, and then tells you how to set the postmaster parameters.
They should not end up in the configure file (unless maybe as comments?)
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, bruce@momjian.us, andrew@dunslane.net, gsmith@gregsmith.com, pgadmin@pse-consulting.de, decibel@decibel.org, peter_e@gmx.net, josh@agliodbs.com
Subject: Re: Overhauling GUCS
In-Reply-To: <25534.1213232184@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox