| From: | Mark Kirkwood <markir(at)paradise(dot)net(dot)nz> | 
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
| Cc: | Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-performance(at)postgresql(dot)org | 
| Subject: | Re: Changing the random_page_cost default (was: | 
| Date: | 2005-03-15 22:44:06 | 
| Message-ID: | 42376536.10500@paradise.net.nz | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-performance | 
Tom Lane wrote:
> "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.
> 
I would like to second that. A while back I performed a number of 
experiments on differing hardware and came to the conclusion that *real* 
random_page_cost was often higher than 4 (like 10-15 for multi-disk raid 
  systems).
However I have frequently adjusted Pg's random_page_cost to be less than 
4 - if it helped queries perform better.
So yes, it looks like the model is the issue - not the value of the 
parameter!
regards
Mark
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Fuhr | 2005-03-15 23:38:34 | Re: Performance problem on delete from for 10k rows. May takes 20 minutes through JDBC interface | 
| Previous Message | Robert Treat | 2005-03-15 21:52:30 | Re: One tuple per transaction |