SQL Tuning and OPTIMIZER - Execution Time with " AND col .."

Question

Hi all,
I get a question about SQL Tuning and OPTIMIZER.
There are three samples with EXPLAIN PLAN and execution time.
This "tw_pkg.getMaxAktion" is a PLSQL Package.
1.) Execution Time : 0.25 Second
2.) Execution Time : 0.59 Second
3.) Execution Time : 1.11 Second
The only difference is some additional "AND col <> .."
Why is this execution time growing so strong?
Many Thanks,
Thomas
----[First example]---
Connected to Oracle Database 10g Enterprise Edition Release 10.2.0.3.0
Connected as dbadmin2
SQL>
SQL> EXPLAIN PLAN FOR
  2  SELECT * FROM ( SELECT studie_id, tw_pkg.getMaxAktion(studie_id) AS max_aktion_id
  3                    FROM studie
  4                 ) max_aktion
  5  WHERE max_aktion.max_aktion_id < 900 ;
Explained
SQL> SELECT * FROM TABLE(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 3201460684
| Id  | Operation            | Name        | Rows  | Bytes | Cost (%CPU)| Time
|   0 | SELECT STATEMENT     |             |   220 |   880 |     5  (40)| 00:00:
|*  1 |  INDEX FAST FULL SCAN| SYS_C005393 |   220 |   880 |     5  (40)| 00:00:
Predicate Information (identified by operation id):
   1 - filter("TW_PKG"."GETMAXAKTION"("STUDIE_ID")<900)
13 rows selected
SQL>
Execution time (PL/SQL Developer says): 0.25 seconds
----[/First]---
----[Second example]---
Connected to Oracle Database 10g Enterprise Edition Release 10.2.0.3.0
Connected as dbadmin2
SQL>
SQL> EXPLAIN PLAN FOR
  2  SELECT * FROM ( SELECT studie_id, tw_pkg.getMaxAktion(studie_id) AS max_aktion_id
  3                    FROM studie
  4                 ) max_aktion
  5  WHERE max_aktion.max_aktion_id < 900
  6    AND max_aktion.max_aktion_id <> 692;
Explained
SQL> SELECT * FROM TABLE(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 3201460684
| Id  | Operation            | Name        | Rows  | Bytes | Cost (%CPU)| Time
|   0 | SELECT STATEMENT     |             |    11 |    44 |     6  (50)| 00:00:
|*  1 |  INDEX FAST FULL SCAN| SYS_C005393 |    11 |    44 |     6  (50)| 00:00:
Predicate Information (identified by operation id):
   1 - filter("TW_PKG"."GETMAXAKTION"("STUDIE_ID")<900 AND
              "TW_PKG"."GETMAXAKTION"("STUDIE_ID")<>692)
14 rows selected
SQL>
Execution time (PL/SQL Developer says): 0.59 seconds
----[/Second]---
----[Third example]---
SQL> EXPLAIN PLAN FOR
  2  SELECT * FROM ( SELECT studie_id, tw_pkg.getMaxAktion(studie_id) AS max_aktion_id
  3                    FROM studie
  4                 ) max_aktion
  5  WHERE max_aktion.max_aktion_id < 900
  6    AND max_aktion.max_aktion_id <> 692
  7    AND max_aktion.max_aktion_id <> 392;
Explained
SQL> SELECT * FROM TABLE(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 3201460684
| Id  | Operation            | Name        | Rows  | Bytes | Cost (%CPU)| Time
|   0 | SELECT STATEMENT     |             |     1 |     4 |     6  (50)| 00:00:
|*  1 |  INDEX FAST FULL SCAN| SYS_C005393 |     1 |     4 |     6  (50)| 00:00:
Predicate Information (identified by operation id):
   1 - filter("TW_PKG"."GETMAXAKTION"("STUDIE_ID")<900 AND
              "TW_PKG"."GETMAXAKTION"("STUDIE_ID")<>692 AND
              "TW_PKG"."GETMAXAKTION"("STUDIE_ID")<>392)
15 rows selected
SQL>
Execution time (PL/SQL Developer says): 1.11 seconds
----[/Third]---Edited by: thomas_w on Jul 9, 2010 11:35 AM
Edited by: thomas_w on Jul 12, 2010 8:29 AM

Answer 1

Hi,
this is likely because SQL Developer fetches and displays only limited number of rows from query results.
This number is a parameter called 'sql array fetch size', you can find it in SQL Developer preferences under Tools/Preferences/Database/Advanced tab, and it's default value is 50 rows.
Query scans a table from the beginning and continue scanning until first 50 rows are selected.
If query conditions are more selective, then more table rows (or index entries) must be scanned to fetch first 50 results and execution time grows.
This effect is usually unnoticeable when query uses simple and fast built-in comparison operators (like = <> etc) or oracle built-in functions, but your query uses a PL/SQL function that is much more slower than built-in functions/operators.
Try to change this parameter to 1000 and most likely you will see that execution time of all 3 queries will be similar.
Look at this simple test to figure out how it works:
CREATE TABLE studie AS
SELECT row_number() OVER (ORDER BY object_id) studie_id,  o.*
FROM (
  SELECT * FROM all_objects
  CROSS JOIN
  (SELECT 1 FROM dual CONNECT BY LEVEL <= 100)
) o;
CREATE INDEX studie_ix ON studie(object_name, studie_id);
ANALYZE TABLE studie COMPUTE STATISTICS;
CREATE OR REPLACE FUNCTION very_slow_function(action IN NUMBER)
RETURN NUMBER
IS
BEGIN
  RETURN action;
END;
/'SQL array fetch size' parameter in SQLDeveloper has been set to 50 (default). We will run 3 different queries on test table.
Query 1:
SELECT * FROM ( SELECT studie_id, very_slow_function(studie_id) AS max_aktion_id
                     FROM studie
              ) max_aktion
WHERE max_aktion.max_aktion_id < 900
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        1      1.22       1.29          0       1310          0          50
total        3      1.22       1.29          0       1310          0          50
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 93  (TEST)
Rows     Row Source Operation
     50  INDEX FAST FULL SCAN STUDIE_IX (cr=1310 pr=0 pw=0 time=355838 us cost=5536 size=827075 card=165415)(object id 79865)
Rows     Execution Plan
      0  SELECT STATEMENT   MODE: ALL_ROWS
     50   INDEX   MODE: ANALYZED (FAST FULL SCAN) OF 'STUDIE_IX' (INDEX)Query 2:
SELECT * FROM ( SELECT studie_id, very_slow_function(studie_id) AS max_aktion_id
                     FROM studie
              ) max_aktion
WHERE max_aktion.max_aktion_id < 900
      AND max_aktion.max_aktion_id > 800
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.01          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        1      8.40       8.62          0       9351          0          50
total        3      8.40       8.64          0       9351          0          50
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 93  (TEST)
Rows     Row Source Operation
     50  INDEX FAST FULL SCAN STUDIE_IX (cr=9351 pr=0 pw=0 time=16988202 us cost=5552 size=41355 card=8271)(object id 79865)
Rows     Execution Plan
      0  SELECT STATEMENT   MODE: ALL_ROWS
     50   INDEX   MODE: ANALYZED (FAST FULL SCAN) OF 'STUDIE_IX' (INDEX)Query 3:
SELECT * FROM ( SELECT studie_id, very_slow_function(studie_id) AS max_aktion_id
                     FROM studie
              ) max_aktion
WHERE max_aktion.max_aktion_id = 600
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.01       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        1     18.72      19.16          0      19315          0           1
total        3     18.73      19.16          0      19315          0           1
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 93  (TEST)
Rows     Row Source Operation
      1  INDEX FAST FULL SCAN STUDIE_IX (cr=19315 pr=0 pw=0 time=0 us cost=5536 size=165415 card=33083)(object id 79865)
Rows     Execution Plan
      0  SELECT STATEMENT   MODE: ALL_ROWS
      1   INDEX   MODE: ANALYZED (FAST FULL SCAN) OF 'STUDIE_IX' (INDEX)Query 1 - 1,29 sec, 50 rows fetched, 1310 index entries scanned to find these 50 rows.
Query 2 - 8,64 sec, 50 rows fetched, 9351 index entries scanned to find these 50 rows.
Query 3 - 19,16 sec, only 1 row fetched, 19315 index entries scanned (full index).
Now 'SQL array fetch size' parameter in SQLDeveloper has been set to 1000.
Query 1:
SELECT * FROM ( SELECT studie_id, very_slow_function(studie_id) AS max_aktion_id
                     FROM studie
              ) max_aktion
WHERE max_aktion.max_aktion_id < 900
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        1     18.35      18.46          0      19315          0         899
total        3     18.35      18.46          0      19315          0         899
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 93  (TEST)
Rows     Row Source Operation
    899  INDEX FAST FULL SCAN STUDIE_IX (cr=19315 pr=0 pw=0 time=20571272 us cost=5536 size=827075 card=165415)(object id 79865)
Rows     Execution Plan
      0  SELECT STATEMENT   MODE: ALL_ROWS
    899   INDEX   MODE: ANALYZED (FAST FULL SCAN) OF 'STUDIE_IX' (INDEX)Query 2:
SELECT * FROM ( SELECT studie_id, very_slow_function(studie_id) AS max_aktion_id
                     FROM studie
              ) max_aktion
WHERE max_aktion.max_aktion_id < 900
      AND max_aktion.max_aktion_id > 800
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        1     18.79      18.86          0      19315          0          99
total        3     18.79      18.86          0      19315          0          99
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 93  (TEST)
Rows     Row Source Operation
     99  INDEX FAST FULL SCAN STUDIE_IX (cr=19315 pr=0 pw=0 time=32805696 us cost=5552 size=41355 card=8271)(object id 79865)
Rows     Execution Plan
      0  SELECT STATEMENT   MODE: ALL_ROWS
     99   INDEX   MODE: ANALYZED (FAST FULL SCAN) OF 'STUDIE_IX' (INDEX)Query 3:
SELECT * FROM ( SELECT studie_id, very_slow_function(studie_id) AS max_aktion_id
                     FROM studie
              ) max_aktion
WHERE max_aktion.max_aktion_id = 600
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        1     18.69      18.84          0      19315          0           1
total        3     18.69      18.84          0      19315          0           1
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 93  (TEST)
Rows     Row Source Operation
      1  INDEX FAST FULL SCAN STUDIE_IX (cr=19315 pr=0 pw=0 time=0 us cost=5536 size=165415 card=33083)(object id 79865)
Rows     Execution Plan
      0  SELECT STATEMENT   MODE: ALL_ROWS
      1   INDEX   MODE: ANALYZED (FAST FULL SCAN) OF 'STUDIE_IX' (INDEX)And now:
Query 1 - 18.46 sec, 899 rows fetched, 19315 index entries scanned.
Query 2 - 18.86 sec, 99 rows fetched, 19315 index entries scanned.
Query 3 - 18.84 sec, 1 row fetched, 19315 index entries scanned.