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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
