Re: [HACKERS] Overhauling GUCS

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers