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

CHAPTER 11 ■ INDEXES 463
If we compare the two examples (unindexed versus indexed), we find that the insert was
affected by a little more than doubling the runtime. However, the select went from over a second
to effectively “instantly.” The important things to note here are the following:
• The insertion of 9,999 records took approximately two times longer. Indexing a userwritten
function will necessarily affect the performance of inserts and some updates.
You should realize that any index will impact performance, of course. For example, I did
a simple test without the MY_SOUNDEX function, just indexing the ENAME column itself.
That caused the INSERT to take about one second to execute—the PL/SQL function is
not responsible for the entire overhead. Since most applications insert and update singleton
entries, and each row took less than 1/10,000 of a second to insert, you probably
won’t even notice this in a typical application. Since we insert a row only once, we pay
the price of executing the function on the column once, not the thousands of times we
query the data.
• While the insert ran two times slower, the query ran many times faster. It evaluated the
MY_SOUNDEX function a few times instead of almost 20,000 times. The difference in performance
of our query here is measurable and quite large. Also, as the size of our table
grows, the full scan query will take longer and longer to execute. The index-based query
will always execute with nearly the same performance characteristics as the table gets
larger.
• We had to use SUBSTR in our query. This is not as nice as just coding WHERE MY_
SOUNDEX(ename)=MY_SOUNDEX( 'King' ), but we can easily get around that, as we will
see shortly.
So, the insert was affected, but the query ran incredibly fast. The payoff for a small reduction
in insert/update performance is huge. Additionally, if you never update the columns
involved in the MY_SOUNDEX function call, the updates are not penalized at all (MY_SOUNDEX is
invoked only if the ENAME column is modified and its value changed).
Now let’s see how to make it so the query does not have use the SUBSTR function call. The
use of the SUBSTR call could be error-prone—our end users have to know to SUBSTR from 1 for
six characters. If they use a different size, the index will not be used. Also, we want to control
in the server the number of bytes to index. This will allow us to reimplement the MY_SOUNDEX
function later with 7 bytes instead of 6 if we want to. We can hide the SUBSTR with a view quite
easily as follows:
ops$tkyte@ORA10G> create or replace view emp_v
2 as
3 select ename, substr(my_soundex(ename),1,6) ename_soundex, hiredate
4 from emp
5 /
View created.
ops$tkyte@ORA10G> exec stats.cnt := 0;
PL/SQL procedure successfully completed.
ops$tkyte@ORA10G> set timing on
ops$tkyte@ORA10G> select ename, hiredate