Re: How is execution plan cost calculated for index scan

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: 高健 <luckyjackgao(at)gmail(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: How is execution plan cost calculated for index scan
Date: 2012-11-08 16:45:37
Message-ID: 27581.1352393137@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

=?UTF-8?B?6auY5YGl?= <luckyjackgao(at)gmail(dot)com> writes:
> I want to see the explain plan for a simple query. My question is : How
> is the cost calculated?

In the case you're looking at, it's basically one random index page
fetch plus one random heap page fetch (hence 8.0), plus assorted CPU
costs making up the other 0.27 cost units.

The argument for charging only for the index leaf-page fetch, and not
upper levels of the index btree, is basically that all but the leaf
level are likely to be in cache. This is pretty handwavy I know, but
the costs seem to come out reasonably in line with reality that way.

> The result returned for path->path.total_cost is 86698968. And
> 86698968/1024/1024 = 82.68258 . If devided by 10 , is near 8.27. but this
> is still a little odd.

Your debugger isn't doing you any favors ... that field is a double.

> In the above case, can I say that the cost formula for index scan is
> in-- the cost_index function ?

cost_index is only responsible for the heap-access part of the charges.
The index-access part is in btcostestimate and genericcostestimate in
utils/adt/selfuncs.c.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Jeff Janes 2012-11-08 17:10:20 Re: Use order by clause, got index scan involved
Previous Message Jeff Janes 2012-11-08 16:40:39 Re: How is execution plan cost calculated for index scan