Struggle to understand the CBO's cost estimates

Question

Hello all
I have a pretty complex query where I struggle to understand the CBO's choices
The middle part which I think should be run first, is a query on a date column, which is indexed by a non-unique normal btree index. But this is only getting chosen is some cases based on the date interval (which in these cases makes the query runs fast), in other cases it's not used, a totallly different plan is then the outcome, and the result is a query which is around 100 times slower
If I take out this middel bit and show a plan for it, its' obvious why.
On some date intervals (which is whole months) the cost is estimated to 4, and on others between 5.000 and 15.000.
Since the number of rows is about the same for each month, and I've just rebuild the index to make sure it's ok, I don't really get why.
This is my simple example
High estimated cost example (count on march):
SELECT COUNT (*) cnt
FROM fmc_pos p
WHERE local_date > TO_DATE ('2010030100', 'yyyymmddhh24')
and local_date < TO_DATE ('2010040100', 'yyyymmddhh24')
Chosen index: IDX_POS_LOCAL_DATE
Estimated cost from plan: 6.394
Estimated index cost from plan: 6.394
Result: 2.718.563
Elapsed time: About 3 sek
Low estimated cost example (count on june):
SELECT COUNT (*) cnt
FROM fmc_pos p
WHERE local_date > TO_DATE ('2010060100', 'yyyymmddhh24')
and local_date < TO_DATE ('2010070100', 'yyyymmddhh24')
Chosen index: IDX_POS_LOCAL_DATE
Estimated cost from plan: 4
Estimated index cost from plan: 4
Result: 2.642.124
Elapsed time: About 3 sek
In both these simple examples the index gets used by the plan, but as you can see the estimated cost is very different, eventhough the number of rows queried is less than 10% different. The execution time is also about the samme
As I mentioned I've just rebuild the index using compute statistics, but that doesn't change anything
Can anybody tell me why the optimizer comes up with costs that are so different on this simple well-balanced index, which then in the full qury makes it choose a very bad plan?
Best Regards
Klaus Mogensen

Answer 1

Yes, this is the version info:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
PL/SQL Release 10.2.0.4.0 - Production
CORE 10.2.0.4.0 Production
TNS for Linux: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production
If I then run the two queries with the hint, and query the plan results I get this information:
The high estimated cost query:
SQL_ID  0kqjnn0mk2cms, child number 0
SELECT /*+ gather_plan_statistics */ COUNT (*) cnt FROM fmc_pos p WHERE local_date > TO_DATE
('2010030100', 'yyyymmddhh24') and local_date < TO_DATE ('2010040100', 'yyyymmddhh24')
Plan hash value: 3346164428
| Id  | Operation         | Name               | Starts | E-Rows | A-Rows |   A-Time   | Buffers | Reads  |
|   1 |  SORT AGGREGATE   |                    |      1 |      1 |      1 |00:00:05.06 |    7206 |   7204 |
|*  2 |   INDEX RANGE SCAN| IDX_POS_LOCAL_DATE |      1 |   2213K|   2715K|00:00:05.65 |    7206 |   7204 |
Predicate Information (identified by operation id):
   2 - access("LOCAL_DATE">TO_DATE(' 2010-03-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
              "LOCAL_DATE"<TO_DATE(' 2010-04-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
The low estimated cost query:
SQL_ID  1w4hx6xsrsr5s, child number 0
SELECT /*+ gather_plan_statistics */ COUNT (*) cnt FROM fmc_pos p WHERE local_date > TO_DATE
('2010060100', 'yyyymmddhh24') and local_date < TO_DATE ('2010070100', 'yyyymmddhh24')
Plan hash value: 3346164428
| Id  | Operation         | Name               | Starts | E-Rows | A-Rows |   A-Time   | Buffers | Reads  |
|   1 |  SORT AGGREGATE   |                    |      1 |      1 |      1 |00:00:02.89 |    7014 |   7012 |
|*  2 |   INDEX RANGE SCAN| IDX_POS_LOCAL_DATE |      1 |     45 |   2642K|00:00:05.32 |    7014 |   7012 |
Predicate Information (identified by operation id):
   2 - access("LOCAL_DATE">TO_DATE(' 2010-06-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
              "LOCAL_DATE"<TO_DATE(' 2010-07-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
I'm not sure whcih info this gives me?
Best regards
Klaus Mogensen
Edited by: user12241627 on 16-Jul-2010 04:44