Received: from localhost (unknown [200.46.204.183]) by developer.postgresql.org (Postfix) with ESMTP id 627D82E00A6 for ; Wed, 11 Jun 2008 22:11:35 -0300 (ADT) Received: from developer.postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 48887-03-6 for ; Wed, 11 Jun 2008 22:11:06 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by developer.postgresql.org (Postfix) with ESMTP id D0A192E005A for ; Wed, 11 Jun 2008 21:56:52 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id m5C0uOqK025535; Wed, 11 Jun 2008 20:56:24 -0400 (EDT) To: Bruce Momjian cc: Andrew Dunstan , Greg Smith , Andreas Pflug , "Decibel!" , Peter Eisentraut , pgsql-hackers@postgresql.org, Josh Berkus Subject: Re: Overhauling GUCS In-reply-to: <200806112340.m5BNea602628@momjian.us> References: <200806112340.m5BNea602628@momjian.us> Comments: In-reply-to Bruce Momjian message dated "Wed, 11 Jun 2008 19:40:36 -0400" Date: Wed, 11 Jun 2008 20:56:24 -0400 Message-ID: <25534.1213232184@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200806/537 X-Sequence-Number: 119650 Bruce Momjian writes: > Tom Lane wrote: >> Bruce Momjian 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