Jim C. Nasby wrote:
On Mon, Apr 24, 2006 at 11:05:18PM -0400, Tom Lane wrote:
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
While the student could do some benchmarking on relatively new
hardware and make suggestions, I agree with Tom. Having to keep
support for older platforms doesn't leave much flexibility to change
the defaults.
Another point here is that the defaults *are* reasonable for development
and for small installations; the people who are complaining are the ones
who expect to run terabyte databases without any tuning. (I exaggerate
perhaps, but the point is valid.)
We've talked more than once about offering multiple alternative
starting-point postgresql.conf files to give people an idea of what to
do for small/medium/large installations. MySQL have done that for years
and it doesn't seem that users are unable to cope with the concept.
But doing this is (a) mostly a matter of testing and documenting, not
coding and (b) probably too small for a SoC project anyway.
My recollection was that there was opposition to offering multiple
config files, but that there was a proposal to make initdb smarter about
picking configuration values.
Personally, I agree that multiple config files would be fine. Or a
really fancy solution would be feeding a config option to initdb and
have it generate an appropriate postgresql.conf.
We have already done some initdb tuning improvements for 8.2 - shared
buffers now tops out at 4000 instead of 1000 and initdb now sets
max_fsm_pages at a more realistic level. (top is 200,000 instead of
previously hardcoded 20,000).
I would have liked to increase max_connections too, but that would have
caused problems on OSX, apparently. See previous discussion.
Personally I would much rather see a tuning advisor tool in more general
use than just provide small/medium/large config setting files.
cheers
andrew
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
