This isn’t a forum, so the very least you could do is find a posting which seems to be relevant to your question rather than posting it at random. I will be deleting your question in a couple of days; in the meantime Timur seems to have pointed you to some interesting related information.

You might note that you haven’t included the Oracle version number in your question – and there have been a number of patches, and upgrades even, since the book came out. I believe the book does point out, by the way that the cost of the index-access for a nested loop is reduced by one if the index is unique – and that’s probably part of the change you see. There’s also a sanity check (not mentioned in the book) that limits the total cost of all the accesses into the index – something along the lines of the cost not exceeding the cost of accessing the entire index once, possibly through an index full scan.

I’ve also observed such behavior some time ago.

explain plan for select
count(*)
from
orders,
lineitem
where
o_orderkey= l_orderkey.

The trace 10053 (as shown below) for this query shows nested loop join with Lineitem as outer table and Orders as inner table. It is effectively join on composite index (pk_lineitem) of Lineitem and unique index(Pk_orderkey) of Orders table. The cost calculation formula as given in the book as “outer table cost + cardinality of outer table * inner table cost ” fails here. I am not able to understand this.

BASE STATISTICAL INFORMATION
***********************
Table Stats::
Table: LINEITEM Alias: LINEITEM
#Rows: 6001215 #Blks: 109048 AvgRowLen: 124.00
Column (#1): L_ORDERKEY(NUMBER)
AvgLen: 6.00 NDV: 1500000 Nulls: 0 Density: 6.6667e-07 Min: 1 Max: 6000000
Index Stats::
Index: LINEITEM_PRTK Col#: 2
LVLS: 2 #LB: 12931 #DK: 197757 LB/K: 1.00 DB/K: 29.00 CLUF: 5812082.00
Index: LINEITEM_SI Col#: 14
LVLS: 2 #LB: 29439 #DK: 4 LB/K: 7359.00 DB/K: 109769.00 CLUF: 439077.00
Index: LINEITEM_SM Col#: 15
LVLS: 2 #LB: 18648 #DK: 7 LB/K: 2664.00 DB/K: 112004.00 CLUF: 784030.00
Index: PK_LINEITEM Col#: 1 4
LVLS: 2 #LB: 15440 #DK: 5879916 LB/K: 1.00 DB/K: 1.00 CLUF: 120630.00
***********************
Table Stats::
Table: ORDERS Alias: ORDERS
#Rows: 1500000 #Blks: 24244 AvgRowLen: 110.00
Column (#1): O_ORDERKEY(NUMBER)
AvgLen: 6.00 NDV: 1500000 Nulls: 0 Density: 6.6667e-07 Min: 163 Max: 5998114
Index Stats::
Index: PK_ORDERS Col#: 1
LVLS: 2 #LB: 3307 #DK: 1500000 LB/K: 1.00 DB/K: 1.00 CLUF: 24045.00

Join order[2]: LINEITEM[LINEITEM]#1 ORDERS[ORDERS]#0
***************
Now joining: ORDERS[ORDERS]#0
***************
NL Join
Outer table: Card: 6001215.00 Cost: 2994.16 Resp: 2994.16 Degree: 1 Bytes: 6
Inner table: ORDERS Alias: ORDERS
Access Path: TableScan
NL Join: Cost: 27976374778.51 Resp: 27976374778.51 Degree: 0
Cost_io: 27873478291.00 Cost_cpu: 2386397111117456
Resp_io: 27873478291.00 Resp_cpu: 2386397111117456
Access Path: index (index (FFS))
Index: PK_ORDERS
resc_io: 633.55 resc_cpu: 203550602
ix_sel: 0.0000e+00 ix_sel_with_filters: 1
Inner table: ORDERS Alias: ORDERS
Access Path: index (FFS)
NL Join: Cost: 3854751895.27 Resp: 3854751895.27 Degree: 0
Cost_io: 3802081121.00 Cost_cpu: 1221551742006481
Resp_io: 3802081121.00 Resp_cpu: 1221551742006481
Access Path: index (UniqueScan)
Index: PK_ORDERS
resc_io: 1.00 resc_cpu: 15293
ix_sel: 6.6667e-07 ix_sel_with_filters: 6.6667e-07
NL Join (ordered): Cost: 10714.35 Resp: 10714.35 Degree: 1
Cost_io: 6722.00 Cost_cpu: 92591405803
Resp_io: 6722.00 Resp_cpu: 92591405803
Access Path: index (AllEqUnique)
Index: PK_ORDERS
resc_io: 1.00 resc_cpu: 15293
ix_sel: 6.6667e-07 ix_sel_with_filters: 6.6667e-07
NL Join (ordered): Cost: 10714.35 Resp: 10714.35 Degree: 1
Cost_io: 6722.00 Cost_cpu: 92591405803
Resp_io: 6722.00 Resp_cpu: 92591405803
Best NL cost: 10714.35
resc: 10714.35 resc_io: 6722.00 resc_cpu: 92591405803
resp: 10714.35 resp_io: 6722.00 resp_cpu: 92591405803

Kindly expalin how the cost has been calculated. This does not follow the traditional nested loop cost formula as mentioned in the book.

Thanks
Regards,

Rekha Singhal

Did you saw:
http://www.dba-village.com/village/dvp_links.LinkDetail?LinkIdA=10707
which lead to:
http://jonathanlewis.wordpress.com/2011/06/23/video/

Is that approved according your knowledge?
:-)

Rg,
Damir Vadas
http://damir-vadas.blogspot.com