alter session set events ’38068 trace name context forever, level 100′;
So IMO this is related to Bug 4112254

Regards
Marie

My test database running on 11.1.0.7 (sun solaris : 64 bit).

Database details:
*********************

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_block_size                        integer     2048
optimizer_mode                       string      ALL_ROWS
db_file_multiblock_read_count        integer     32
compatible                           string      11.1.0


Tablespace details:
*********************


SQL> select TABLESPACE_NAME,ALLOCATION_TYPE,EXTENT_MANAGEMENT,SEGMENT_SPACE_MANAGEMENT from  dba_tablespaces;

TABLESPACE_NAME                ALLOCATIO EXTENT_MAN SEGMEN
------------------------------ --------- ---------- ------
TABLE001                       USER      DICTIONARY MANUAL




SQL> create table t1(  
  2      DATE1              DATE,  
  3      STRING1            VARCHAR2(40),  
  4      NUM1               NUMBER,  
  5      NUM2               NUMBER,  
  6      NUM3               NUMBER,  
  7      NUM4               NUMBER,  
  8      NUM5               NUMBER,  
  9      STRING2            VARCHAR2(3),  
 10      NUM6               NUMBER,  
 11      STRING3            VARCHAR2(240),  
 12      STRING4            VARCHAR2(240),  
 13      STRING5            VARCHAR2(240),  
 14      STRING6            VARCHAR2(240),  
 15      STRING7            VARCHAR2(240),  
 16      STRING8            VARCHAR2(240),  
 17      STRING9            VARCHAR2(10)  
 18  );  

Table created.

SQL> insert into t1(  
  2      date1, num1, num3, num6, string9  
  3  )  
  4  select  
  5      sysdate + dbms_random.value(-180, +180),  
  6      trunc(dbms_random.value(0,10)),  
  7      trunc(dbms_random.value(0,10)),  
  8      trunc(dbms_random.value(0,10)),  
  9      dbms_random.string('U',6)  
 10  from dual  
 11  connect by  
 12      rownum  commit;

Commit complete.

SQL> 
SQL> CREATE INDEX t1_i1 ON t1 (TRUNC(DATE1), NUM3);  

Index created.

SQL> 
SQL> CREATE INDEX t1_i2 ON t1 (NUM3, NUM1, TRUNC(DATE1));  

Index created.



SQL> begin  
  2      dbms_stats.gather_table_stats(  
  3          ownname      => 'TEST',  
  4          tabname      =>'T1',  
  5          estimate_percent => 100,  
  6          block_sample     => true,  
  7          method_opt   => 'for all columns size 1',  
  8          cascade      => true  
  9      );  
 10  end;  
 11  /  

PL/SQL procedure successfully completed.

SQL> explain plan for  
  2  SELECT  
  3      NVL(SUM(num6),0) num6_SUM  
  4  FROM t1  
  5  WHERE  
  6      1 = 1  
  7  and num3 = :b1  
  8  AND TRUNC(date1) BETWEEN sysdate-:b2 AND sysdate-:b3  
  9  and string9 = :b4  
 10  ;  

Explained.

SQL> select * from table(dbms_xplan.display)  ;  

PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------
Plan hash value: 683166071

---------------------------------------------------------------------------------------
| Id  | Operation                     | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT              |       |     1 |    21 |     1   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE               |       |     1 |    21 |            |          |
|*  2 |   FILTER                      |       |       |       |            |          |
|*  3 |    TABLE ACCESS BY INDEX ROWID| T1    |     1 |    21 |     1   (0)| 00:00:01 |
|*  4 |     INDEX RANGE SCAN          | T1_I2 |    18 |       |     1   (0)| 00:00:01 |
---------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - filter(SYSDATE@!-TO_NUMBER(:B2)=SYSDATE@!-TO_NUMBER(:B2) AND
              TRUNC(INTERNAL_FUNCTION("DATE1"))=SYSDATE@!-TO_NUMBER(:B2) AND
              TRUNC(INTERNAL_FUNCTION("DATE1")) explain plan for  
  2  SELECT  
  3      /*+ index(t1 t1_i1) */  
  4      NVL(SUM(num6),0) num6_SUM  
  5  FROM t1  
  6  WHERE  
  7      1 = 1  
  8  AND num3 = :b1  
  9  AND TRUNC(date1) BETWEEN sysdate-:b2 AND sysdate-:b3  
 10  and string9 = :b4  
 11  ;  

Explained.

SQL> select * from table(dbms_xplan.display)  ;

PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------
Plan hash value: 2267170846

---------------------------------------------------------------------------------------
| Id  | Operation                     | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT              |       |     1 |    21 |     1   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE               |       |     1 |    21 |            |          |
|*  2 |   FILTER                      |       |       |       |            |          |
|*  3 |    TABLE ACCESS BY INDEX ROWID| T1    |     1 |    21 |     1   (0)| 00:00:01 |
|*  4 |     INDEX RANGE SCAN          | T1_I1 |    18 |       |     1   (0)| 00:00:01 |
---------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - filter(SYSDATE@!-TO_NUMBER(:B2)=SYSDATE@!-TO_NUMBER(:B2) AND
              "NUM3"=TO_NUMBER(:B1) AND TRUNC(INTERNAL_FUNCTION("DATE1"))<=SYSDATE@!-TO_NUMBE
              R(:B3))
       filter("NUM3"=TO_NUMBER(:B1))

21 rows selected.

Thanks Lewis.

Regards
Rajabaskar Thangaraj

Your argument is rational, but ought to be backed up by arithmetic.

The optimizer can make a reasonable estimate of the fraction of data that would be returned by “columnX = ‘unknown constant’” because it can work on the basis of “number of distinct values for columnX”.

For “columnD between pair of unknown constants” Oracle uses a guess of 0.25%. The problem is this – when should Oracle be INCONSISTENT in its arithmetic and ignore the number it usually uses for the guess.

Let’s pretend that columnX has only one known value – should Oracle take the index that starts with columnX – which means it has to scan the whole index – or should it take the index that starts with columnD because in the worst case it will have to scan the whole index but it may scan much less.

Clearly, in this extreme case, it is arguably more sensible to use the index that starts with the column using the range-based predicate.

So – one distinct value is a special case where your rational approach should be ignored. How many distinct values should Oracle allow before it decides that it’s no longer looking at a special case ? (This is the type of question the designers and developers have to ask themselves when trying to create a cost-based optimiser.)

I meant to say the index would be preferred which is created on the columns with ‘=’ operators in the predicates than the the columns with the Range operator

Yes, it is very useful, and of course those “fixed in” notations are misleading, what with backports and screaming customers and all – wrong results must be taken more seriously than “mere” optimizer issues.

The development environment I work in has had this functionality, as part of local “db-blind” dictionary extensions, for many years, and it is used all over the place, very useful. Of course, not being part of the db engine, it is easy to mess up when trying to manipulate data through sql, as in this implementation these virtual columns look like regular columns, so you update them, and that gets overwritten by the app. I look forward with interest as to how the vendor will deal with integrating the Oracle functionality, if they do, it would certainly help if the db were aware and these things could be indexed.

I wonder if you tried the same test without using bind variables if you would get the same result. From the tests Charles ran it looks as if it is the bind variables that cause the higher cost path to be chosen and that seems to be what Johnwuwuwu is saying.

I would post the links to Tom’s presentation but it doesn’t seem to be up yet (assuming it will be).

Thanks for that information – even though it is rather worrying and means I will have to look at this example a lot more closely because your comment raises lots of questions:

Is this just function-based indexes, or all indexes
Is it purely heuristic, or is there some arithmetic bias as well
Does this apply to all cases of comparison with “unknown” such as:

• colX between plsql_function(const1) and plsql_function(const2)
• colx between (non-correlated scalar subquery 1) and (non-correlated scalar subquery 2)
• colx between sys_context() and sys_context()
• t2.cox between t1.cola and t1.colb

If it is more generic than function-based indexes, I’m puzzled that I haven’t noticed it before. I guess this will give me something to do on my next long-haul flight.

Thanks for the comment. I assume that Tom was reminding people that “explain plan” doesn’t know the type of the bind variables and doesn’t have any values to peek.

In this case, though, the problem isn’t so much the fact that we get the wrong plan because of those failings, it’s that with (nominally) a self-consistent level of information the optimizer does the wrong thing.