> Bruce Momjian <bruce@momjian.us> writes:
> > Tom Lane wrote:
> >> 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;
My initial thought was that this would behave like a shell script
variable, meaning once you set something it would affect all references
to it below in postgresql.conf. The problem with that is that we
comment out all settings, so there isn't a logical order like you would
have in a shell script.
I was not thinking of memory_usage implicity changing anything. I
figured postgresql.conf would have:
memory_usage = 100
work_mem = $memory_usage * 0.75
If you change memory_usage via SET, it will not change work_mem at all
because you are not re-initializing the variables.
I am kind of lost how this would work logically and am willing to think
about it some more, but I do think we aren't going to simplify
postgresql.conf without such a facility.
The big problem I see is that right now everything has a constant
default. If we allowed memory_usage to change some of the defaults, how
would we signal that we want the variables based on it to change their
values? This is your behind-the-scenes problem you mentioned.
> 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?)
I am concerned that each wizzard is going to have to duplicate the same
logic each time, and adjust to release-based changes. I thought having
the configuration file itself help with setting some values would be
helpful.
--
Bruce Momjian <bruce@momjian.us>
EnterpriseDB
+ If your life is a hard drive, Christ can be your backup. +
--
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