Because date columns can include time components, one of the versions loses the data that starts after (day only) 12th Feb and ends before (day only) 13th Feb – i.e. everything from “12-Feb-2010 00:00:01″ to “12-Feb-2010 23:59:59″.

Physically there may be no such data (because of the application code, perhaps), but logically the database has no information that tells it that such rows cannot exist.

Maybe i am overlooking something very common or my first post was not clear enough.

You said:
> The first thing to note about these queries is that they are not logically equivalent even
though they may have produced the same result

If i check the access predicates between the following code:
——————-8<——————–
(
t1.date_col
between to_date('01-feb-2010','dd-mon-yyyy') and to_date('12-feb-2010','dd-mon-yyyy')
or
t1.date_col
between to_date('13-feb-2010','dd-mon-yyyy')
and to_date('25-feb-2010','dd-mon-yyyy')
)
——————-8<——————–

and the original predicates
——————-8<——————–
t1.date_col
between to_date('01-feb-2010','dd-mon-yyyy')
and to_date('25-feb-2010','dd-mon-yyyy')
——————-8<——————–

Why are they logical different?

If i check the acess predicates between the original statement and the OR concetanation, the access predicates on DATE_COL are the logical the same, or?

Thanks and Regards
Stefan

The column is of type DATE, but you’re overlooking the fact that a DATE column in Oracle is implicitly date-and-time with a granularity of one second.

Just one short question to the following “assumption”:
> It’s possible that the end user knows that the data in column date_col is always date-only (which is the constraint which would ensure the two queries return identical results) but the database (hence the optimizer) doesn’t know this

I guess, that the column date_col is of colum n type DATE.
So why shouldn’t the optimizer know that the result of the “OR results” always will be date? You only can store “date”-data in this column, or?

Thanks and Regards
Stefan

I remember the entertaining time you had with using the “obviously sensible” check constraints. And your reference to the bugfix posted by Oracle.

I’ll have to run my tests on 10.2.0.4 and 11.1 upwards – but the effect on this 10.2.0.3 test case is even more “amusing” than you might at first guess.

I think that the problem of check constraints causing incorrect estimated cardinalities wasn’t fixed until 10.2.0.4, as I recall. Another CBO surprise!

I just did a quick re-run with optimizer_dynamic_sampling set to 4, and it didn’t change the plans. (sampling took place in both cases, and – with the 10g seed() call in the sample size – the estimated cardinality was the same for both plans at 1,238 rows. That’s not surprising given the actual data – it favours Oracle getting a reasonable estimate using its standard arithmetic.

I was just a little surprised that this drop didn’t make the full tablescan plan change to a bitmap conversion, but I still don’t have a complete picture of the optimizer’s costing of bitmaps and bitmap conversions.

Update: I’ve just realised that another effect on costing is that the nature of the predicate forces Oracle to consider taking two bites (not bytes) at the index, so we’re also seeing an anomaly similar to the “OR” adjustment where the cost of scanning two adjacent sections of an index is not the same as the cost of scanning the entire range in one bite.

News for today – I’ve decided to switch on the “Nero” ratings on the blog to see if this tells me anything about how useful my notes are. I may switch them off if they seem to be slowing down the speed that pages load.

I wonder what happens if you set DYNAMIC_SAMPLING to above the default value of 2 for V10.2? I’d predict the CBO would check the guesses about correlation it made and revert back to the full tabe scan…
If I get chance, I’ll try to replicate your test.