> 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
No comments:
Post a Comment