Re: Overhauling GUCS - Mailing list pgsql-hackers

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