10.2.0.4 CBO behavior without histograms and binds/literals

Question

Hello,
i have a question about the CBO and the collected statistic values LOW_VALUE and HIGH_VALUE. I have seen the following on an oracle 10.2.0.4 database.
The CBO decides for a different execution plan, if we use bind variables (without bind peeking) or literals - no histograms exist on the table columns.
Unfortunately i didn't export the statistics to reproduce this behaviour on my test database, but it was "something" like this.
Environment:
- Oracle 10g 10.2.0.4
- Bind peeking disabled (_optim_peek_user_binds=FALSE)
- No histograms
- No partitioned table/indexes
The table (TAB) has 2 indexes on it:
- One index (INDEX A1) has included the date (which was a NUMBER column) and the values in this columns spread from 0 (LOW_VALUE) up to 99991231000000 (HIGH_VALUE).
- One index (INDEX A2) has included the article number which was very selective (distinct keys nearly the same as num rows)
Now the query looks something like this:
SELECT * FROM TAB WHERE DATE BETWEEN :DATE1 AND :DATE2 AND ARTICLENR = :ARTNR;And the CBO calculated, that best execution plan would be a index range scan on both indexes and perform a btree-to-bitmap conversion .. compare the returned row-ids of both indexes and then access the table TAB with that.
What the CBO didn't know (because of the disabled bind peeking) was, that the user has entered DATE1 (=0) and DATE2 (=99991231000000) .. so the index access on index A1 doesn't make any sense.
Now i executed the query with literals just for the DATE .. so query looks something like this:
SELECT * FROM TAB WHERE DATE BETWEEN 0 AND 99991231000000 AND ARTICLENR = :ARTNR;And then the CBO did the right thing ... just access index A2 which was very selective and then acceesed the table TAB by ROWID.
The query was much faster (factor 4 to 5) and the user was happy.
As i already mentioned, that there were no historgrams i was very amazed, that the execution plan changed because of using literals.
Does anybody know in which cases the CBO includes the values in LOW_VALUE and HIGH_VALUE in its execution plan calcuation?
Until now i thought that these values will only be used in case of histograms.
Thanks and Regards

Answer 1

oraS wrote:
As i already mentioned, that there were no historgrams i was very amazed, that the execution plan changed because of using literals.
Does anybody know in which cases the CBO includes the values in LOW_VALUE and HIGH_VALUE in its execution plan calcuation?
Until now i thought that these values will only be used in case of histograms.I don't have any references in front of me to confirm but my estimation is that the LOW_VALUE and HIGH_VALUE are used whenever there is a range based predicate, be it, the BETWEEN or any one of the <, >, <=, >= operators. Generally speaking the selectivity formula is the range defined in the query over the HIGH_VALUE/LOW_VALUE range. There are some specific variations of this due to including the boundaries (<= vs <) and NULL values. This make sense to use when the literal values are known or the binds are being peaked at.
However, when bind peaking is disabled Oracle has no way to use the general formula above for an estimation of the rows so it mostly likely uses the 5% rule. Since in your query you have a BETWEEN clause the estimated selectivity becomes 5%*5% which equals 0.0025. This estimated cardinality could be what made the CBO decide to use the index path versus ignoring it completely.
If you can post some sample data to reproduce this test case we can confirm.
Just a follow-up question. Why is a date being stored as a number?
HTH!