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:

https://jonathanlewis.wordpress.com/2011/06/23/video/

Is that approved according your knowledge?

:-)

Rg,

Damir Vadas

http://damir-vadas.blogspot.com