I’m using a function-based index with a user-defined function for the first time, and have stumbled across a performance problem when the index can’t be used.
Internally, a function-based index seems to generate a hidden table column (of type varchar2(4000), since my function returns a varchar2), and indexes that. That works fine when the index is used, but sometimes we have to do a full table scan using the function as a filter, and in that case I see a performance degradation by a factor of 6. Seems in that case, Oracle does not use the hidden column, but recomputes the function for each row, make the query CPU-bound instead of IO-bound.
Is there a way to make Oracle use that hidden column also for filtering? I wonder if I’m missing some rewrite options or something along those lines.
If not, I’ll have to define the column myself and using a trigger to keep it up to date. I’d prefer using the function-based index for transparency and easier maintanance.
There is no general way a function-based index can be used in a table scan.
The assumption I made in my question, namely “Internally, a function-based index seems to generate a hidden table column …”, is simply wrong: the results of the function are not stored in a table column, but only in the index.
So, unless there is a way to access the index when performing the scan (the only way I can think of is if it’s a combined index starting with the key column(s)), the precomputed function result can’t be used.
The 11g “virtual column” feature does not help either, as the column is not stored in the table, but computed on-the-fly, similar to using the function in a view.
In summary: if you can’t rule out table scans, and your function call is expensive (slow), use a real column in combination with a “before insert or update” trigger. A function-based index won’t do.
(Note: Added this answer because I did not want to let this question stand as unanswered. The credit for the answer belongs to thilo, who pointed out that the column is never materialized).