Andrew Dunstan wrote:
> I accept the "run from init.d" argument. So then, is there a case for
> increasing the limits that initdb works with, to reflect the steep
> rise we have seen in typically available memory at the low end?
There is a compromise that I think we cannot make. For production
deployment, shared buffers are typically sized at about 10% to 25% of
available phyiscal memory. I don't think we want to have a default
installation of PostgreSQL that takes 10% or more of memory just like
that. It just doesn't look good.
So the question whether initdb should by default consider up to 1000 or
up to 4000 buffers is still worth discussion, but doesn't solve the
tuning issue to a reasonable degree.
What I would like to see is that initdb would end with saying that the
system is not really tuned and that I should run pg-some-program to
improve that. pg-some-program would analyze my system, ask me a few
questions, and then output a suggested configuration (or apply it right
away). Again, the challenge is to write that program.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
