Re: How is execution plan cost calculated for index scan - Mailing list pgsql-general

From Tom Lane
Subject Re: How is execution plan cost calculated for index scan
Date
Msg-id 27581.1352393137@sss.pgh.pa.us
Whole thread Raw
In response to How is execution plan cost calculated for index scan  (高健 <luckyjackgao@gmail.com>)
List pgsql-general
=?UTF-8?B?6auY5YGl?= <luckyjackgao@gmail.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


pgsql-general by date:

Previous
From: Jeff Janes
Date:
Subject: Re: How is execution plan cost calculated for index scan
Next
From: Jeff Janes
Date:
Subject: Re: Use order by clause, got index scan involved