On Mon, Oct 26, 2009 at 3:30 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>> This actually seems like a bad idea to me.
> You write your tool your way, I'll write my tool mine. We'll see which
> one works the best in the field.
Yeah actually I meant to but YMMV on that comment and forgot.
>> Well you're assuming there's only one tool generating this config? We
>> have at least two and possibly more. initdb generates an initial set
>> of defaults, the user may well run some kind of autotuning program,
>> and then they also have variables set by SET PERSISTENT. That's three
>> pieces of configuration being edited by different pieces of software.
> Well, that's what I'd call a bad idea. Mixing external autotuner which
> writes to files with SET PERSISTENT?
Well you'll need a story for that. You can't stop users from doing SET
PERSISTENT and you'll probably want to adjust some of the variables
that initdb sets up too.
I'm thinking a typical postgresql.d directory would contain
And also of course read postgresql.conf for any manual settings.
When you run autotuner you could either check if any variables have a
source which comes after 50autotuner.conf and take them into account
or just dump your settings into 50autotuner.conf and then give a
warning if any of them are overridden.
Likewise I would expect SET PERSISTENT to check if any variables have
a source which comes later than 99persistent.conf (namely
postgresql.conf normally) and give a warning. (but still dump the
variable into the 99persistent.conf file)
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2009-10-26 23:42:39|
|Subject: Re: per-tablespace random_page_cost/seq_page_cost |
|Previous:||From: Greg Stark||Date: 2009-10-26 23:35:24|
|Subject: Re: per-tablespace random_page_cost/seq_page_cost|