Re: Overhauling GUCS - Mailing list pgsql-hackers

On Jun 11, 2008, at 9:34 PM, Bruce Momjian wrote:
> Tom Lane wrote:
>> 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.

Why? That's the exact opposite of what I'd expect. If I want a  
setting's value to be $memory_usage * .75, that's what I want it to  
be. Not some value based on whatever $memory_usage was set to when  
work_mem happened to be changed.

Of course, if you set something to a hard value with no variables,  
then that's what it's set to.

> 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.

Agreed. And I think it's a lot more elegant for dealing with day-to- 
day tuning than some kind of external wizzard.

> 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.


I would suggest that we just re-evaluate everything whenever any  
setting is changed (this assumes that we store postgresql.conf  
internally in some fashion, so that we're not actually hitting the  
file all the time and possibly picking up random edits).
-- 
Decibel!, aka Jim C. Nasby, Database Architect  decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828