Re: Changing the random_page_cost default (was: cpu_tuple_cost) - Mailing list pgsql-performance

From Jeff Hoffmann
Subject Re: Changing the random_page_cost default (was: cpu_tuple_cost)
Date
Msg-id 8dd8c52718f9c9153fe089d64a496150@propertykey.com
Whole thread Raw
In response to Re: Changing the random_page_cost default (was: cpu_tuple_cost)  ("Greg Sabino Mullane" <greg@turnstep.com>)
List pgsql-performance
On Mar 15, 2005, at 6:35 AM, Greg Sabino Mullane wrote:

> Granted, I don't work on
> any huge, complex, hundreds of gig databases, but that supports my
> point -
> if you are really better off with a /higher/ (than 3)
> random_page_cost, you
> already should be tweaking a lot of stuff yourself anyway.

I think this is a good point.  The people that tend to benefit from the
lower cost are precisely the people least likely to know to change it.
It's the "install & go" crowd with smaller databases and only a few
users/low concurrency that expect it to "just work".  The bigger
installations are more like to have dedicated DB admins that understand
tuning.

Wasn't there an idea on the table once to ship with several different
configuration files with different defaults for small, medium, large,
etc. installs?  Wouldn't it make sense to ask the user during initdb to
pick from one of the default config files?  Or even have a few simple
questions like "How much memory do you expect to be available to
PostgreSQL?" and "How many concurrent users do you expect to have?".
It's one thing to know how much memory is in a machine, it quite
another thing to know how much the user wants dedicated to PostgreSQL.
A couple of questions like that can go a long way to coming up with
better ballpark figures.

--
Jeff Hoffmann
jeff@propertykey.com


pgsql-performance by date:

Previous
From: "Greg Sabino Mullane"
Date:
Subject: Re: Changing the random_page_cost default (was: cpu_tuple_cost)
Next
From: Chris Mair
Date:
Subject: interesting benchmarks PG/Firebird Linux/Windows fsync/nofsync