Re: planner costs in "warm cache" tests

On Mon, May 31, 2010 at 3:55 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Jesper Krogh <jesper(at)krogh(dot)cc> writes:
>> On 2010-05-30 20:34, Tom Lane wrote:
>>> Well, hmm, I really doubt that that represents reality either.  A page
>>> access is by no means "free" even when the page is already in cache.
>>> I don't recall anyone suggesting that you set these numbers to less
>>> than perhaps 0.01.
>>>
>> Thank you for the prompt response. Is it a "false assumption" that the
>> cost should in some metric between different plans be a measurement
>> of actual run-time in a dead-disk run?
>
> Well, the default cost parameters (seq_page_cost=1, random_page_cost=4)
> are intended to model the non-cached state where most page fetches
> actually do require a disk access.  They are definitely too large
> relative to the cpu_xxx_cost parameters when you have a fully-cached
> database, but what I've seen people recommending for that condition
> is to set them both to the same value in the vicinity of 0.1 or 0.01
> or so.  If it's only mostly cached you might try intermediate settings.

I have had to set it as low as .005 to get the right things to happen.
Could have been a fluke, I suppose.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company