Re: BUG #9552: IndexOnlyScan startup_cost>0, why not equal 0?it's a bug? - Mailing list pgsql-bugs

From Kyotaro HORIGUCHI
Subject Re: BUG #9552: IndexOnlyScan startup_cost>0, why not equal 0?it's a bug?
Date
Msg-id 20140313.143426.16396458.horiguchi.kyotaro@lab.ntt.co.jp
Whole thread Raw
In response to BUG #9552: IndexOnlyScan startup_cost>0, why not equal 0?it's a bug?  (digoal@126.com)
List pgsql-bugs
Hello,

> I belive index only scan can return tuple direct, it's not need to scan
> heappage, why it's startup_cost equal to index scan?
> I'ts a bug?

No. It is a result of reasonable calculus.

>  Index Scan using t11_pkey on t11  (cost=0.29..4.31 rows=1 width=9)

Index scan runs through several disk (but usually on cache)
blocks during descending down to the leaf node in the index tree
and does comparisons for certain amount of index entries(tuples)
in each index node with regard to btree. The figure made from the
expected number of the comparisons multiplied by
cpu_operator_cost. Each access methods (index types) has their
own function to do that.

=# select amname, amcostestimate from pg_am where amname = 'btree';
 amname | amcostestimate
--------+----------------
 btree  | btcostestimate

The function 'btcostestimate' in selfuncs.c calculates it for
btree index. You can see the details there if you wish.

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center

pgsql-bugs by date:

Previous
From: David Johnston
Date:
Subject: Re: BUG #9554: won't connect
Next
From: Kyotaro HORIGUCHI
Date:
Subject: Re: BUG #9553: why bitmap index scan startup_cost=0? it's a bug?