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