mlw writes:
> I have been thinking about postgresql.conf and I have made a few posts already
> about it. My concern is that Postgres, as default, is not very well tuned. One
> can even say the default is pretty much a bad configuration.
The default configuration is mainly guided by three sometimes
contradictory aspects: It should be reasonably secure, "unusual" or
non-standard features are turned off, and resources are regulated so that
it is easy to "try out" PostgreSQL without having to do major kernel
tuning first or bringing other applications down to their knees. I think
the default settings for most parameters are not really disputed, it's
only the performance and resource-related settings that you want to work
on.
> How about this: we have just just two or three default configuration files?
> Compact, Workstation, and server.
Trying to elimate the one-size-does-not-fit-all problem with
N-sizes-fit-all cannot be an optimal idea considering the dimensionality
of the space of possible configurations. If all you're concerned about is
buffers and sort memory it's much easier to say "configure buffers to use
1/4 of available memory" than to make arbitrary guesses about the
available memory and attach arbitrary labels to them.
Theoretically, it should be possible to determine optimal values for all
performance-related settings from a combination of benchmarks, a few
questions asked of the user about the system configuration and the
expected work load, and a dynamic analysis of the nature of the data.
But a system of formulas describing these relationsships is incredibly
difficult to figure out and solve. If it weren't, we could get rid of all
these settings and allocate resources dynamically at run time.
What we ought to do, however, is to collect and document empirical methods
for tuning, such as the above "1/4 of available memory" rule (which does
not claim to be correct, btw.).
--
Peter Eisentraut peter_e@gmx.net