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

From Tom Lane
Subject Re: Changing the random_page_cost default (was: cpu_tuple_cost)
Date
Msg-id 6320.1110900176@sss.pgh.pa.us
Whole thread Raw
In response to Re: Changing the random_page_cost default (was: cpu_tuple_cost)  ("Greg Sabino Mullane" <greg@turnstep.com>)
Responses Re: Changing the random_page_cost default (was:
Re: Changing the random_page_cost default (was: cpu_tuple_cost)
List 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 by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: interesting benchmarks PG/Firebird Linux/Windows fsync/nofsync
Next
From: Stef
Date:
Subject: Slow loads when indexes added.