Re: Improving postgresql.conf

Tom, folks:

> The only real problem I see is that showing all the values as comments
> encourages the idea that you can undo a change by undoing your edit.
> The simple and obvious fix is to not show the values as comments ...

I'll say!    I've been testing PostgreSQL.conf settings, writing docs for 
them, etc. for several years now and this is the first I was aware that 
commenting out lines would not reset the defaults.   Mind you, that's partly 
because I don't think I've ever re-commented anything; but certainly if I can 
be confused about this, then the majority of our users are likewise confused.

My thoughts:

1) Uncomment everything in the postgresql.conf file.   As long as we have 
commented out values, people will think that commented == default.

2) I think the easiest way to let people know the defaults for .conf is to 
have initdb generate a 2nd file called postgresql.conf.defaults.   This will 
allow them to compare and reset -- or even copy over -- if things get too 
messed up.   The second way is to list the defaults in our documentation.

3) Like Bruce, I think it would be nifty to have a postgresql.conf.large file 
to give people the hint about tuning for modern servers.   However, the 
problem is that many settings hinge on the exact machine configuration; i.e. 
the specific amount of memory, whether or not the DB is bigger than RAM, how 
fast the disk array is, etc.   Further, some settings vary pretty strongly 
between types of database; the config file for a transaction-processing DB is 
quite different from an OLAP server.Finally, there's the issue that we'll need significant testing on 7.5 before 
we're confident what the best memory settings *are*.    Jan's work changes 
the balance between reserved and kernel memory significantly.

-- 
Josh Berkus
Aglio Database Solutions
San Francisco