Peter Eisentraut wrote:
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.
I have a single instance of apache running on this machine. It's not
doing anything, but even so it's consuming 20% of physical memory. By
contrast, my 3 postmasters are each consuming 0.5% of memory. All with
default settings. I don't think we are in any danger of looking bad for
being greedy. If anything we are in far greater danger of looking bad
from being far too conservative and paying a performance price for that.
There's nothing magical about the numbers we use.
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.
True, but that doesn't mean it's not worth doing anyway.
cheers
andrew
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
