Received: from localhost (unknown [200.46.204.183]) by developer.postgresql.org (Postfix) with ESMTP id BEEAF2E0045 for ; Wed, 11 Jun 2008 22:46:47 -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 83016-09 for ; Wed, 11 Jun 2008 22:46:37 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from westnet.com (westnet.com [216.187.52.2]) by developer.postgresql.org (Postfix) with ESMTP id 97FA82E0041 for ; Wed, 11 Jun 2008 22:46:42 -0300 (ADT) Received: from westnet.com (localhost [127.0.0.1]) by westnet.com (8.14.0/8.14.0) with ESMTP id m5C1kX08017458; Wed, 11 Jun 2008 21:46:33 -0400 (EDT) Received: from localhost (gsmith@localhost) by westnet.com (8.14.0/8.13.2/Submit) with ESMTP id m5C1kXNr017454; Wed, 11 Jun 2008 21:46:33 -0400 (EDT) X-Authentication-Warning: westnet.com: gsmith owned process doing -bs Date: Wed, 11 Jun 2008 21:46:33 -0400 (EDT) From: Greg Smith X-X-Sender: gsmith@westnet.com To: Tom Lane cc: Bruce Momjian , pgsql-hackers@postgresql.org, Josh Berkus Subject: Re: Overhauling GUCS In-Reply-To: <25534.1213232184@sss.pgh.pa.us> Message-ID: References: <200806112340.m5BNea602628@momjian.us> <25534.1213232184@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200806/542 X-Sequence-Number: 119655 On Wed, 11 Jun 2008, Tom Lane wrote: > 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.) People are already exposed to issues in this area via things like the include file mechanism. You can think of that two ways. You can say, "there's already problems like this so who cares if there's another one". Or, you can say "let's not add even more confusion like that". Having a mini programming language for setting parameters is interesting and all, and it might be enough to do a good job of handling the basic newbie setup chores. But I don't think it's a complete solution and therefore I find moving in that direction a bit of a distraction; your concerns about ambiguity just amplify that feeling. It's unlikely that will get powerful enough to enable the "one true config file" that just works for everybody. There's too many things that depend a bit on both data access pattern and on overall database size/structure no matter what you do. [If only there were some technology that did workload profiling and set the server parameters based on that. Some sort of dynamic tuning tool; wouldn't that be great? Oh well, that's just a dream right now I guess.] I'm not sure if I've stated this explicitly yet, but I personally have no interest in just solving the newbie problem. I want a tool to help out tuning medium to large installs, and generating a simple config file is absolutely something that should come out of that as a bonus. Anything that just targets the simple installs, though, I'm not very motivated to chase after. -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD