Re: Changing the random_page_cost default (was: cpu_tuple_cost)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Greg Sabino Mullane" <greg(at)turnstep(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Changing the random_page_cost default (was: cpu_tuple_cost)
Date: 2005-03-15 15:22:56
Message-ID: 6320.1110900176@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

"Greg Sabino Mullane" <greg(at)turnstep(dot)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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Stef 2005-03-15 15:23:45 Slow loads when indexes added.
Previous Message Bruce Momjian 2005-03-15 13:55:34 Re: interesting benchmarks PG/Firebird Linux/Windows fsync/nofsync