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
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 |