Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005

CHAPTER 11 ■ INDEXES 479
Predicate Information (identified by operation id):
---------------------------------------------------
2 - filter(TO_NUMBER("X")=5)
it uses the index, but not for a UNIQUE SCAN as we might expect—it is FULL SCANNING this index.
The reason lies in the last line of output there: filter(TO_NUMBER("X")=5). There is an implicit
function being applied to the database column. The character string stored in X must be converted
to a number prior to comparing to the value 5. We cannot convert 5 to a string, since
our NLS settings control what 5 might look like in a string (it is not deterministic), so we convert
the string into a number, and that precludes the use of the index to rapidly find this row.
If we simply compare strings to strings
ops$tkyte@ORA10GR1> delete from plan_table;
2 rows deleted.
ops$tkyte@ORA10GR1> explain plan for select * from t where x = '5';
Explained.
ops$tkyte@ORA10GR1> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
-------------------------------------------------------------------
Plan hash value: 1301177541
------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 12 | 1 (0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| T | 1 | 12 | 1 (0)| 00:00:01 |
|* 2 | INDEX UNIQUE SCAN | T_PK | 1 | | 1 (0)| 00:00:01 |
------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - access("X"='5')
we get the expected INDEX UNIQUE SCAN, and we can see the function is not being applied.
You should always avoid implicit conversions anyway. Always compare apples to apples and
oranges to oranges. Another case where this comes up frequently is with dates. We try to
query:
-- find all records for today
select * from t where trunc(date_col) = trunc(sysdate);
and discover that the index on DATE_COL will not be used. We can either index the
TRUNC(DATE_COL) or, perhaps more easily, query using range comparison operators. The
following demonstrates the use of greater than and less than on a date. Once we realize
that the condition
TRUNC(DATE_COL) = TRUNC(SYSDATE)