I was wondering whether the 100 was an upper bound for range predicates that were out of range – but it seems not.

Thanks for the offer – I finally got around to installing OEL and 11.2 on my daughter’s old laptop last night.

Thanks for that – I’m running on 10.2.0.3 at the moment.
I wonder if the change is hidden somewhere in the code relating to frequency histograms that appeared in that upgrade.

>I still haven’t got around to installing 11.2 so can’t investigate at present.
If you need a VMware image of OEL5u4 with 11.2.0.1 EE, I can upload it (I think it’s about 8GB in compressed form).

s14 82
s15 73
s14-17 100
s14-16 100
s14-18 100
s14-21 100
s14-27 100
s21-22 100
s21-23 100
s21-24 100

Thanks for that tip. I still haven’t got around to installing 11.2 so can’t investigate at present.

It’s possible that it’s deliberate – for example the out-of-range queries may be limited to the maximum single value in range.

Do you get 100 for a range of (say) 21 – 22, then 21 – 23, then 21 – 24, or do you get an increasing set of values ? Can you pick another set of ranges and see a set of results that increase until they hit 100 ?

There are a couple of minor variations on the theme – but the basic answer is that that’s the selectivity in this case for “column = (non-popular) constant”.

Do you know why the optimizer uses 100 as the point to count back from? Does this change given the size of the table?

Thanks,

John

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.