From: Joshua D. Drake <jd@commandprompt.com>
To: Simon Riggs <simon@2ndquadrant.com>
Cc: Josh Berkus <josh@agliodbs.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Overhauling GUCS
Date: Sat, 31 May 2008 08:14:58 -0700
Message-ID: <48416B72.3060203@commandprompt.com> (raw)
In-Reply-To: <1212219274.4120.191.camel@ebony.site>
References: <48409D1E.3070208@agliodbs.com>
<1212219274.4120.191.camel@ebony.site>
Simon Riggs wrote:
> On Fri, 2008-05-30 at 17:34 -0700, Josh Berkus wrote:
> We have many supporters, though 90% of them seldom touch the database
> from one release to the next. Many are dismayed that every time they do
> we've fiddled with the knobs so some don't work anymore, some are
> missing or renamed and there's a few new ones.
I certainly agree we don't want to make it more difficult.
>
> So if they don't know
> what they're doing it is frequently because we keep moving the
> goalposts.
No, its because they don't read the docs. We are not talking about
dumping SQL here :) I don't feel it is correct to not perform such a
needed cleanup for fear that some user can't be bothered to read the
documentation.
> We should also consider that most people with multiple databases are
> running multiple versions of PostgreSQL. The main reason for that is
> that we keep changing the behaviour of SQL between releases, so even if
> you had a magic superfast upgrade utility, in perhaps 50% of cases they
> won't use it because they have to do a full application re-test, which
> costs time and money.
This could certainly be a problem.
>
> Trying to be a Postgres DBA is hard when each new release is configured
> differently to the last one and we have a major release about 3-5 more
> frequently than Oracle/SQLServer. That is probably largest source of
> questions and annoyance from the students on the courses I run.
That is the nature of the beast though. We are still learning,
improving, engineering. It's part of progress of the database. I would
suggest that your students (which is what I tell mine) not upgrade every
release but instead try hanging out for 3 years per release.
>
> So my viewpoint is that we should be aggressively adding new features,
> yet be conservative in changing existing behaviour: provide options for
> behaves-like-previous-release and keep the administrative interfaces as
> similar as possible between releases.
>
I agree with this in principle but not on this argument.
> If you wish to make changes, I would suggest that you simply reorder
> some of the parameters in the .conf file, so that the ones you think are
> important are grouped at the top.
IMO, the only settings that should be in the postgresql.conf are the
ones that require a restart. The rest should be gathered from pg_settings.
>
> Another suggestion would be to allow a #include style interface within
> postgresql.conf. We can then do this:
>
> #include standard_postgresql.conf
>
> # now we put Josh's favourite GUCs as overrides on the above
> ...
I think that could get very messy but Apache allows this. It isn't
exactly a new idea and I wouldn't fight against it.
> Some other problems I see with GUCs
>
> * It's not possible to set one parameter depending upon the setting of
> another.
That is getting a bit more complicated than I think we need. Unless I am
misunderstanding what you are saying.
>
> * It's always unclear which GUCs can be changed, and when. That is much
> more infrequently understood than the meaning of them.
>
This is a definite problem. Even the docs are a bit difficult on this
one. It should be a nice simple grid :) or like I said above, only goes
in the conf if requires a restart.
Hmm,
SET effective_cache_size = '5000MB';
WARNING: You must issue a reload to the database for this to take effect.
> * We should rename effective_cache_size to something that doesn't sound
> like it does what shared_buffers does
Hmmm, I wonder if it is not the other way around. Although I know that
one thing I run into is that a lot of people think effective_cache is an
allocation.
shared_buffer_alloc?
shared_mem?
>
> * There is no config verification utility, so if you make a change and
> then try to restart and it won't, you are in trouble.
>
+1 +1
Sincerely,
Joshua D. Drake
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: jd@commandprompt.com, simon@2ndquadrant.com, josh@agliodbs.com
Subject: Re: Overhauling GUCS
In-Reply-To: <48416B72.3060203@commandprompt.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox