Re: Changing the random_page_cost default (was: cpu_tuple_cost)

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Changing the random_page_cost default (was: cpu_tuple_cost)
Дата
Msg-id 6320.1110900176@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Changing the random_page_cost default (was: cpu_tuple_cost)  ("Greg Sabino Mullane" <greg@turnstep.com>)
Ответы Re: Changing the random_page_cost default (was:  (Mark Kirkwood <markir@paradise.net.nz>)
Re: Changing the random_page_cost default (was: cpu_tuple_cost)  ("Greg Sabino Mullane" <greg@turnstep.com>)
Список pgsql-performance
"Greg Sabino Mullane" <greg@turnstep.com> writes:
> N.B. My own personal starting default is 2, but I thought 3 was a nice
> middle ground more likely to reach consensus here. :)

Your argument seems to be "this produces nice results for me", not
"I have done experiments to measure the actual value of the parameter
and it is X".  I *have* done experiments of that sort, which is where
the default of 4 came from.  I remain of the opinion that reducing
random_page_cost is a band-aid that compensates (but only partially)
for problems elsewhere.  We can see that it's not a real fix from
the not-infrequent report that people have to reduce random_page_cost
below 1.0 to get results anywhere near local reality.  That doesn't say
that the parameter value is wrong, it says that the model it's feeding
into is wrong.

            regards, tom lane

В списке pgsql-performance по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: interesting benchmarks PG/Firebird Linux/Windows fsync/nofsync
Следующее
От: Stef
Дата:
Сообщение: Slow loads when indexes added.