Question

I’ve written a scalar function (DYNAMIC_DATE) that converts a text value to a date/time. For example, DYANMIC_DATE('T-1') (T-1 = today minus 1 = ‘yesterday’) returns 08-AUG-2012 00:00:00. It also accepts date strings: DYNAMIC_DATE('10/10/1974').

The function makes use of CASE statements to parse the sole parameter and calculate a date relative to sysdate.

While it doesn’t make use of any table in its schema, it does make use of TABLE type to store date-format strings:

TYPE VARCHAR_TABLE IS TABLE OF VARCHAR2(10);
formats VARCHAR_TABLE := VARCHAR_TABLE ('mm/dd/rrrr','mm-dd-rrrr','rrrr/mm/dd','rrrr-mm-dd');

When I use the function in the SELECT clause, the query returns in < 1 second:

SELECT  DYNAMIC_DATE('MB-1') START_DATE, DYNAMIC_DATE('ME-1') END_DATE
FROM    DUAL

If I use it against our date dimension table (91311 total records), the query completes in < 1 second:

SELECT  count(1)
from    date_dimension
where   calendar_dt between DYNAMIC_DATE('MB-1') and  DYNAMIC_DATE('ME-1')

Others, however, are having problems with the function if it is used against a larger table (26,301,317 records):

/*
cost: 148,840
records: 151,885
time: ~20 minutes
*/
SELECT  count(1)
FROM    ORDERS ord
WHERE   trunc(ord.ordering_date) between DYNAMIC_DATE('mb-1') and DYNAMIC_DATE('me-1')

However, the same query, using ‘hard coded’ dates, returns fairly rapidly:

/*
cost: 144,257
records: 151,885
time: 62 seconds
*/
SELECT  count(1)
FROM    ORDERS ord
WHERE   trunc(ord.ordering_date) between to_date('01-JUL-2012','dd-mon-yyyy') AND to_date('31-JUL-2012','dd-mon-yyyy')

The vendor’s vanilla installation doesn’t include an index on the ORDERING_DATE field.

The explain plans for both queries are similar:

with function:

with hard-coded dates:

• Is the DYNAMIC_DATE function being called repeatedly in the WHERE clause?
• What else might explain the disparity?

** edit **

A NONUNIQUE index was added to ORDERS table. Both queries execute in < 1 second. Both plans are the same (approach), but the one with the function is lower cost.

I removed the DETERMINISTIC keyword from the function; the query executed in < 1 second.

• Is the issue really with the function or was it related to the table?
• 3 years from now, when this table is even larger, and if I don’t include the DETERMINISTIC keyword, will query performance suffer?
• Will the DETERMINISTIC keyword have any affect on the function’s results? If I run DYNAMIC_DATE('T-1') tomorrow, will I get the same results as if I ran it today (08/09/2012)? If so, this approach won’t work.

Answer 1

If the steps of the plan are identical, then the total amount of work being done should be identical. If you trace the session (something simple like set autotrace on in SQL*Plus or something more sophisticated like an event 10046 trace), or if you look at DBA_HIST_SQLSTAT assuming you have licensed access to the AWR tables, are you seeing (roughly) the same amount of logical I/O and CPU consumption for the two queries? Is it possible that the difference in runtime you are seeing is the result of the data being cached when you run the second query?