Re: Changing the random_page_cost default (was:
От | Mark Kirkwood |
---|---|
Тема | Re: Changing the random_page_cost default (was: |
Дата | |
Msg-id | 42376536.10500@paradise.net.nz обсуждение исходный текст |
Ответ на | Re: Changing the random_page_cost default (was: cpu_tuple_cost) (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-performance |
Tom Lane wrote: > "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. > 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
В списке pgsql-performance по дате отправления: