Re: Relation of cpu_*_costs?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: SZŰCS Gábor <surrano(at)mailbox(dot)hu>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Relation of cpu_*_costs?
Date: 2004-06-07 13:51:56
Message-ID: 2604.1086616316@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

"=?iso-8859-2?B?U1rbQ1MgR+Fib3I=?=" <surrano(at)mailbox(dot)hu> writes:
> Last week I fumbled with CPU_TUPLE_COST and revealed that 4 out of 4 tested
> queries improved by 10-60% if I changed it from 0.01 (default) to 0.40
> (ugh). Setting it higher did not bring any improvement.

That's pretty hard to believe; particularly on modern machines, I'd
think that moving it down would make more sense than moving it up.
You're essentially asserting that the CPU time to process one tuple
is almost half of the time needed to bring a page in from disk.

I suspect that your test cases were toy cases small enough to be
fully cached and thus not incur any actual I/O ...

> [ trying to get a nestloop indexscan plan to be generated ]

I believe that the planner's cost model for nestloops with inner
indexscan is wrong: it costs each inner iteration independently, when
in fact there should be some savings, because at least the topmost
levels of the index will soon be fully cached. However, when I tried
to work out a proper model of this effect, I ended up with equations
that gave higher indexscan costs than what's in there now :-(. So that
didn't seem like it would make anyone happy.

regards, tom lane

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2004-06-07 15:11:21 Re: Postgres function use makes machine crash.
Previous Message Stef 2004-06-07 11:34:15 Postgres function use makes machine crash.