Tom Lane wrote:
>Peter Eisentraut <peter_e@gmx.net> writes:
>
>
>>All jokes aside, tuning aids are surely needed, but letting initdb guess
>>the required profile isn't going to do it.
>>
>>
>
>initdb is really the wrong place for this anyway, because in many
>situations (RPM installations for instance) initdb is run behind the
>scenes with no opportunity for user interaction. We should be doing
>our best to remove options from initdb, not add them.
>
>I think Andrew has a good point that we need to work more on making
>configuration tuning easier ... but initdb isn't the place.
>
>
>
>
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? We currently
try {100, 50, 40, 30, 20, 10} for connections and {1000, 900, 800, 700,
600, 500, 400, 300, 200, 100, 50} for buffers. I think there's arguably
a good case for trying numbers several (4 maybe?) times this large in
both categories. Out own docs state that the default number of shared
buffers is low for efficient use, and it would be nice to try to allow
one connection per standard allowed apache client (default is 256
non-threaded and 400 threaded, I think).
cheers
andrew