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

460
CHAPTER 11 ■ INDEXES
Now that we have the function MY_SOUNDEX, let’s see how it performs without an index.
This uses the EMP table we created earlier with about 10,000 rows in it:
ops$tkyte@ORA10G> set timing on
ops$tkyte@ORA10G> set autotrace on explain
ops$tkyte@ORA10G> select ename, hiredate
2 from emp
3 where my_soundex(ename) = my_soundex('Kings')
4 /
ENAME HIREDATE
---------- ---------
Ku$_Chunk_ 10-AUG-04
Ku$_Chunk_ 10-AUG-04
Elapsed: 00:00:01.07
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=32 Card=100 Bytes=1900)
1 0 TABLE ACCESS (FULL) OF 'EMP' (TABLE) (Cost=32 Card=100 Bytes=1900)
ops$tkyte@ORA10G> set autotrace off
ops$tkyte@ORA10G> set timing off
ops$tkyte@ORA10G> set serveroutput on
ops$tkyte@ORA10G> exec dbms_output.put_line( stats.cnt );
19998
PL/SQL procedure successfully completed.
We can see this query took over one second to execute and had to do a full scan on the
table. The function MY_SOUNDEX was invoked almost 20,000 times (according to our counter),
twice for each row.
Let’s see how indexing the function can speed up things. The first thing we’ll do is create
the index as follows:
ops$tkyte@ORA10G> create index emp_soundex_idx on
2 emp( substr(my_soundex(ename),1,6) )
3 /
Index created.
The interesting thing to note in this CREATE INDEX command is the use of the SUBSTR function.
This is because we are indexing a function that returns a string. If we were indexing a
function that returned a number or date, this SUBSTR would not be necessary. The reason we
must SUBSTR the user-written function that returns a string is that such functions return
VARCHAR2(4000) types. That may well be too big to be indexed—index entries must fit within
about three quarters the size of a block. If we tried, we would receive (in a tablespace with a
4KB blocksize) the following: