Query strage behavior

Question

Hi,
I tried to ask this before, but it came again.
I have an application query (which means I can't really change it) with a condition in the beginning.
When the condition is false - it should be very fast.
However - it is checking the second condition anyway.
version 11.2.0.2
optimizer_features_enable 11.2.0.2
SQL Text
select :intvar from DUAL where ( to_number(:TINVOICES$IV$) <> 0 ) and exists ( select 'X' from TABULA.macdent$FNCITEMS where ( macdent$FNCITEMS.QIV = to_number(:TINVOICES$IV$) ) )
Global Information
Status : DONE (ALL ROWS)
Instance ID : 1
Session : VINEVICH (1434:13395)
SQL ID : cxnwuby99fddr
SQL Execution ID : 16777223
Execution Started : 04/01/2012 16:15:44
First Refresh Time : 04/01/2012 16:15:44
Last Refresh Time : 04/01/2012 16:17:12
Duration : 88s
Module/Action : TABULA/WINFORM TINVOICES -g C:\TMP\AAAD
Service : pri
Program : WINFORM.exe
Fetch Calls : 1
Binds Name Position Type Value
:TINVOICES$IV$ 2 NUMBER 0 -------> This is the value of the variable - 0
:TINVOICES$IV$ 3 NUMBER 0
Global Stats Elapsed
Time(s) Cpu
Time(s) IO
Waits(s) Cluster
Waits(s) Other
Waits(s) Fetch
Calls Buffer
Gets Read
Reqs Read
Bytes
177 24 153 0.00 0.20 1 1M 8777 8GB
Parallel Execution Details (DOP=2 , Servers Allocated=2)
Name Type Server# Elapsed
Time(s) Cpu
Time(s) IO
Waits(s) Cluster
Waits(s) Other
Waits(s) Buffer
Gets Read
Reqs Read
Bytes Wait Events
(sample #)
PX Coordinator QC 0.21 0.00 0.20 13 .
p000 Set 1 1 88 11 77 520K 4095 4GB db file scattered read (80)
p001 Set 1 2 89 12 76 0.00 578K 4682 4GB db file scattered read (86)
SQL Plan Monitoring Details (Plan Hash Value=883410849) Id Operation Name Rows
(Estim) Cost Time
Active(s) Start
Active Execs Rows
(Actual) Read
Reqs Read
Bytes Activity
(%) Activity Detail
(# samples)
0 SELECT STATEMENT 1
1 . FILTER 1
2 .. FAST DUAL 1 2
3 .. PX COORDINATOR 1 +88 3 1
4 ... PX SEND QC (RANDOM) :TQ10000 64M 2 87 +2 2 2 0.57 Cpu (1)
5 .... PX BLOCK ITERATOR 64M 2 87 +2 2 60M
6 ..... TABLE ACCESS FULL MACDENT$FNCITEMS 64M 2 88 +1 42 60M 8777 8GB 99.43 Cpu (9)
db file scattered read (166)
So - the condition 0<0 is FLASE. why Oracle checks the second condition as well??
Thanks

Answer 1

It's amazing how sometimes a simple case can surprise you.
You're right and it's not a new thing either.
SQL> create table t1
  2  as
  3  select * from dba_objects;
Table created.
SQL> var n number
SQL> var n2 number
SQL> exec :n := 0
PL/SQL procedure successfully completed.
SQL> exec :n2 := 1
PL/SQL procedure successfully completed.
SQL> select /*+ monitor gather_plan_statistics*/
  2         :n2
  3  from   t2
  4  where  :n > 0
  5  and    exists (select 1 from t1 where object_name = 'T1');
no rows selected
SQL>
SQL> select * from table(dbms_xplan.display_cursor(null,null,'ALLSTATS LAST'));
PLAN_TABLE_OUTPUT
SQL_ID  8tmd7ptyd0dh3, child number 0
select /*+ monitor gather_plan_statistics*/        :n2 from   t2 where
:n > 0 and    exists (select 1 from t1 where object_name = 'T1')
Plan hash value: 2132554994
| Id  | Operation          | Name | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
|   0 | SELECT STATEMENT   |      |      1 |        |      0 |00:00:00.02 |     868 |
|*  1 |  FILTER            |      |      1 |        |      0 |00:00:00.02 |     868 |
|   2 |   TABLE ACCESS FULL| T2   |      0 |      1 |      0 |00:00:00.01 |       0 |
|*  3 |   TABLE ACCESS FULL| T1   |      1 |     11 |      1 |00:00:00.02 |     868 |
Predicate Information (identified by operation id):
   1 - filter(( IS NOT NULL AND :N>0))
   3 - filter("OBJECT_NAME"='T1')
Note
   - dynamic sampling used for this statement (level=4)
26 rows selected.
SQL> Whereas if we'd written the bind check into the subquery, then it has the desired shortcut effect.
SQL> select /*+ monitor gather_plan_statistics*/
  2         :n2
  3  from   dual
  4  where  exists (select 1 from t1 where :n > 0 and object_name = 'T1');
no rows selected
SQL>
SQL> select * from table(dbms_xplan.display_cursor(null,null,'ALLSTATS LAST'));
PLAN_TABLE_OUTPUT
SQL_ID  gjtrmbtczvsrr, child number 0
select /*+ monitor gather_plan_statistics*/        :n2 from   dual
where  exists (select 1 from t1 where :n > 0 and object_name = 'T1')
Plan hash value: 4023761791
| Id  | Operation           | Name | Starts | E-Rows | A-Rows |   A-Time   |
|   0 | SELECT STATEMENT    |      |      1 |        |      0 |00:00:00.01 |
|*  1 |  FILTER             |      |      1 |        |      0 |00:00:00.01 |
|   2 |   FAST DUAL         |      |      0 |      1 |      0 |00:00:00.01 |
|*  3 |   FILTER            |      |      1 |        |      0 |00:00:00.01 |
|*  4 |    TABLE ACCESS FULL| T1   |      0 |     11 |      0 |00:00:00.01 |
Predicate Information (identified by operation id):
   1 - filter( IS NOT NULL)
   3 - filter(:N>0)
   4 - filter("OBJECT_NAME"='T1')
Note
   - dynamic sampling used for this statement (level=4)
28 rows selected.
SQL> So, yes it's surprising but it's not new behaviour and funny things can happen depending on how you write something.