Bruce Momjian <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> Bruce Momjian <[EMAIL PROTECTED]> 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