Re: Changing the random_page_cost default (was: cpu_tuple_cost)

Поиск
Список
Период
Сортировка
От Jeff Hoffmann
Тема Re: Changing the random_page_cost default (was: cpu_tuple_cost)
Дата
Msg-id 8dd8c52718f9c9153fe089d64a496150@propertykey.com
обсуждение исходный текст
Ответ на Re: Changing the random_page_cost default (was: cpu_tuple_cost)  ("Greg Sabino Mullane" <greg@turnstep.com>)
Список 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 по дате отправления:

Предыдущее
От: "Greg Sabino Mullane"
Дата:
Сообщение: Re: Changing the random_page_cost default (was: cpu_tuple_cost)
Следующее
От: Chris Mair
Дата:
Сообщение: interesting benchmarks PG/Firebird Linux/Windows fsync/nofsync