Can you have uploaded your presentation on

(1)how to write efficient SQL
(2)Partitioning

Thanks

Thanks for the comment. If it’s a really complex query with lots of subqueries, remember that it’s possible to postpone thinking about the subqueries in the first drafts. And if it’s any consolation, I often find that it takes three or four attempts to draw the picture for a really complicated query – I always seem to end up with 10 tables crammed into a tiny corner of the paper in the early attempts.

It’s the kind of thing that you’d think would be obvious… Ah well, that’s why we have these kinds of conferences, etc, right? Right?! *{;-)

Thanks. I know you did not write specification or code. The only reason for asking the WHY question was I have seen you demonstrate how CBO works (or might be working) in many other cases.

explain plan set statement_id='s14' for
select count(*) from audience where month_no = 14;

explain plan set statement_id='s15' for
select count(*) from audience where month_no = 15;

explain plan set statement_id='s14-17' for
select count(*) from audience where month_no between 14 and 17;

explain plan set statement_id='s14-16' for
select count(*) from audience where month_no between 14 and 16;

explain plan set statement_id='s14-18' for
select count(*) from audience where month_no between 14 and 18;

explain plan set statement_id='s14-21' for
select count(*) from audience where month_no between 14 and 21;

explain plan set statement_id='s14-27' for
select count(*) from audience where month_no between 14 and 27;

select statement_id, cardinality
  from plan_table
 where statement_id like 's1%' and id = 2;

STATEMENT_ID                   CARDINALITY
------------------------------ -----------
s14                                     82
s15                                     73
s14-17                                 100
s14-16                                 100
s14-18                                 100
s14-21                                 100
s14-27                                 100

or this is a bug, since 10053 reports “Using prorated density: 0.068182″ which should result in cardinality of 82, but reports cardinality just like for a MONTH_NO=CONST predicate.

Don’t ask me WHY Oracle uses a given strategy – I didn’t write the specification or code; however I think that Timur’s suggestion is probably the right one.

The number of rows reported after using explain plan is the optimizer’s estimate of the number that will be produced (for each call to that line of the plan). It’s a figure that may be completely wrong.