Thanks for your reply.

]]>Oracle’s cardinality = 15458

Oracle’s number of rows input = 309157

So Oracle’s selectivity = 15458 / 309157 = 0.05000049

Oracle has used the standard 5% for “column > unknown value” in this case.

]]>However, cardinality estimate is off. My column is not null column with FBI on it (upper(column)) and no popular values.

Predicate is “col like :bindvar||’%’”. Bind value is within range.

NewDensity:0.000015, OldDensity:0.000239 BktCnt:254, PopBktCnt:0, PopValCnt:0, NDV:67072 Column (#41): SYS_NC00041$( AvgLen: 50 NDV: 67072 Nulls: 0 Density: 0.000015 Histogram: HtBal #Bkts: 254 UncompBkts: 254 EndPtVals: 255 Card: Original: 309157.000000 Rounded: 15458 Computed: 15457.85 Non Adjusted: 15457.85

Cardinality = 0.000015 * 309157 = 4.637355 vs 15458 (computed by CBO)

Not sure what type of math I should do for a unbounded range…

Will try to figure out by going through your book. But, do you by any chance think this is a bug?

Appreciate your contribution to Oracle community,

Thanks!

Thanks for your time and Thanks for the comments too.

There’s lot of predicates on the given table and not particularly using any index and doing a full table scan. To add more, the query in the question is having problem only on monday after a table re-org (ofcourse stats has been gathered after rebuild) and rest of the days its back to normal. No change in plans and nothing, hence trying to cornering how the cost has been derived. Will further dig more.

I must say, I have been learning a lot with your blog and your nice book “CBO – fundamentals”, Thank you…

Regards

Suresh

It can take some time to work these things out, and it’s not a particularly interesting or educational task; so I only do it when I’m being paid to do it or puzzled by an example that’s appeared in a forum.

In your example there are two things that would make it harder to do: (a) every column has a histogram – so you might have to look at the histogram data in great detail, and (b) you haven’t told me what the predicates are that the optimizer will be evaluating at this point – and not that they may NOT be exactly the predicates you wrote in your initial query.

]]>Would you able to help me in understanding the cardinality from the following output, how was 1642 derived?

SINGLE TABLE ACCESS PATH Single Table Cardinality Estimation for TRADE[T] Column (#2): NewDensity:0.000001, OldDensity:0.000001 BktCnt:5402, PopBktCnt:5402, PopValCnt:4, NDV:4 Column (#105): NewDensity:0.000001, OldDensity:0.000001 BktCnt:5402, PopBktCnt:5402, PopValCnt:2, NDV:2 Column (#55): NewDensity:0.000002, OldDensity:0.000002 BktCnt:2835, PopBktCnt:2835, PopValCnt:2, NDV:2 Column (#1): NewDensity:0.000002, OldDensity:0.000002 BktCnt:254, PopBktCnt:0, PopValCnt:0, NDV:443488 Column (#72): NewDensity:0.000001, OldDensity:0.000001 BktCnt:5402, PopBktCnt:5402, PopValCnt:2, NDV:4 Column (#6): NewDensity:0.001419, OldDensity:0.002012 BktCnt:254, PopBktCnt:10, PopValCnt:5, NDV:682 Column (#159): NewDensity:0.000003, OldDensity:0.000038 BktCnt:254, PopBktCnt:2, PopValCnt:1, NDV:310528 Column (#16): NewDensity:0.000002, OldDensity:0.000005 BktCnt:254, PopBktCnt:10, PopValCnt:1, NDV:426496 Column (#157): NewDensity:0.000001, OldDensity:0.000001 BktCnt:5402, PopBktCnt:5402, PopValCnt:3, NDV:4 Column (#155): NewDensity:0.000215, OldDensity:0.001799 BktCnt:254, PopBktCnt:81, PopValCnt:13, NDV:3175 Column (#4): NewDensity:0.000001, OldDensity:0.000001 BktCnt:5178, PopBktCnt:5178, PopValCnt:6, NDV:7 ColGroup (#1, Index) IDX_TRD_DVP_FEX Col#: 1 2 5 8 53 60 73 105 108 CorStregth: -1.00 ColGroup (#2, Index) IDXTRDTAX Col#: 1 2 55 68 72 105 135 CorStregth: 52038.16 ColGroup (#8, Index) IDX_TRADE_FX Col#: 1 2 5 8 105 108 CorStregth: -1.00 ColGroup (#5, Index) IDX$$_4B290002 Col#: 2 6 154 155 156 CorStregth: 2298053781278.98 ColGroup (#7, Index) FEXIGNOREEXCEPTION_712A0001 Col#: 2 5 8 105 108 CorStregth: -1.00 ColGroup (#6, Index) IDX_TRADE_COMM Col#: 2 4 5 153 CorStregth: -1.00 ColGroup (#9, Index) IDX$$_50990001 Col#: 6 7 12 CorStregth: -1.00 ColGroup (#10, Index) TRADE_UK1 Col#: 1 6 46 CorStregth: -1.00 ColGroup (#3, Index) IDX$$_173D0004 Col#: 6 159 CorStregth: 575.99 ColGroup (#4, Index) IDX$$_4B2C0004 Col#: 16 157 CorStregth: 4.00 ColGroup Usage:: PredCnt: 4 Matches Full: Partial: Table: TRADE Alias: T Card: Original: 471074.000000 Rounded: 1642 Computed: 1641.93 Non Adjusted: 1641.93 Access Path: TableScan Cost: 12436.31 Resp: 12436.31 Degree: 0 Cost_io: 12338.00 Cost_cpu: 2113927982 Resp_io: 12338.00 Resp_cpu: 2113927982]]>

Thanks so much for explaining .I do have your book – cost based oracle -fundamentals, but I could not find the discussion on cost of unique index access ,but I do see some sort of discussion on it in chapter 11 . (nested loops).

Yes the blevel of the unique index which is a PK is 1 . you are absolutely correct .

Kindly point out where in the cost based oracle -fundamentals, I could see more details on this.

I have a hard copy and I might have skipped that section inadvertantely.

Regards.

Ajeet

I think this is an example covered in my book * “Cost Based Oracle – Fundamentals”*, but I can’t be completely certain since I don’t have all the information about your tables and indexes in front of me. The basic points, however, are this:

a) the orders_pk index looks like it might be the index on a primary key column

b) for index-only access on unique indexes the optimizer subtracts 1 from the normal index-only cost

c) for index access by nested loop the optimizeir subtracts 1 from the expected cost

I suspect from this that your index has a blevel of 1: so the cost of “select o_orderkey from orders where o_orderkey = {constant}” has a cost of 1, and the cost of accessing just the order key in the nested loop is zero.

]]>What could be the possible reason of COST = 0 for unique index scan operation of the following query and plan. I am not able to understand the reason.

Could you please help.

sql_id=52a0skswvaqvk. Current SQL statement for this session: explain plan for select count(*) from orders, lineitem where o_orderkey = l_orderkey ============ Plan Table ============ ---------------------------------------------+-----------------------------------+ | Id | Operation | Name | Rows | Bytes | Cost | Time | ---------------------------------------------+-----------------------------------+ | 0 | SELECT STATEMENT | | | | 343 | | | 1 | SORT AGGREGATE | | 1 | 10 | | | | 2 | NESTED LOOPS | | 583K | 5830K | 343 | 00:00:05 | | 3 | INDEX FAST FULL SCAN | PK_LINEITEM| 586K | 2932K | 294 | 00:00:05 | | 4 | INDEX UNIQUE SCAN | PK_ORDERS | 1 | 5 | 0 | | ---------------------------------------------+-----------------------------------+ Predicate Information: ---------------------- 4 - access("O_ORDERKEY"="L_ORDERKEY") Content of other_xml column =========================== db_version : 10.2.0.1 parse_schema : EMUDSS plan_hash : 2594599139 Outline Data: /*+ BEGIN_OUTLINE_DATA IGNORE_OPTIM_EMBEDDED_HINTS OPTIMIZER_FEATURES_ENABLE('10.2.0.1') ALL_ROWS OUTLINE_LEAF(@"SEL$1") INDEX_FFS(@"SEL$1" "LINEITEM"@"SEL$1"("LINEITEM"."L_ORDERKEY" "LINEITEM"."L_LINENUMBER")) INDEX(@"SEL$1" "ORDERS"@"SEL$1" ("ORDERS"."O_ORDERKEY")) LEADING(@"SEL$1" "LINEITEM"@"SEL$1" "ORDERS"@"SEL$1") USE_NL(@"SEL$1" "ORDERS"@"SEL$1") END_OUTLINE_DATA */]]>