Difference between join conditions using NVL and not using NVL

Question

Hi,
I have a join condition in one of the applications as follows.
NVL(RQ.out_mesg_id,0) = NVL(RS.out_mesg_id,0)How is it different without using NVL function. What is the internal execution difference.
RQ.out_mesg_id = RS.out_mesg_idWill there be any difference in Performance and also in the query output.
Regards,
Pabolu

Answer 1

Pabolu wrote:
Hi,
I have a join condition in one of the applications as follows.
NVL(RQ.out_mesg_id,0) = NVL(RS.out_mesg_id,0)How is it different without using NVL function. What is the internal execution difference.
RQ.out_mesg_id = RS.out_mesg_idWill there be any difference in Performance and also in the query output.
Regards,
PaboluI suppose that's a bit of a trick question (or could be).
If the column is allowed to be NULL, then your 2 queries are NOT equivalent, so comparing isn't useful since presumably you can only have one correct result :)
However, if RQ and RS (no idea what the table names are) are both defined as having a NOT NULL constraint on the column out_mesg_id (ignoring the possibility of column level masking possible with the use of VPD here) then the optimizer could do better if you rewrote the query without the use of NVL (this would of course depend on your tables, indexes, etc ... i am merely showing you that it COULD make a difference).
SQL> select * from v$version;
BANNER                                                                         
Oracle Database 10g Express Edition Release 10.2.0.1.0 - Product               
PL/SQL Release 10.2.0.1.0 - Production                                         
CORE     10.2.0.1.0     Production                                                     
TNS for 32-bit Windows: Version 10.2.0.1.0 - Production                        
NLSRTL Version 10.2.0.1.0 - Production                                         
SQL>
SQL> create table t1 as
  2  select level as col1, case when mod(level, 10) = 0 then null else mod(level, 10) end as col2
  3  from dual connect by level <= 1000;
Table created.
SQL>
SQL> alter table t1 add constraint t1_pk primary key (col1);
Table altered.
SQL>
SQL> create index t1_i_001 on t1 (col2);
Index created.
SQL>
SQL> exec dbms_stats.gather_table_stats(user, 'T1', cascade => true);
PL/SQL procedure successfully completed.
SQL>
SQL> create table t2 as
  2  select level as col1, case when mod(level, 100) = 0 then null else mod(level, 100) end as col2
  3  from dual connect by level <= 1000;
Table created.
SQL>
SQL> alter table t2 add constraint t2_pk primary key (col1);
Table altered.
SQL>
SQL> create index t2_i_001 on t2 (col2);
Index created.
SQL>
SQL> exec dbms_stats.gather_table_stats(user, 'T2', cascade => true);
PL/SQL procedure successfully completed.
SQL>
SQL> --query using NVL
SQL> explain plan for
  2  select count(*)
  3  from t1, t2
  4  where nvl(t1.col1, 0) = nvl(t2.col1, 0)
  5  /
Explained.
SQL>
SQL> SELECT * FROM table(DBMS_XPLAN.DISPLAY);
PLAN_TABLE_OUTPUT                                                              
Plan hash value: 663667122                                                     
| Id  | Operation              | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT       |       |     1 |     8 |     5  (20)| 00:00:01 |
|   1 |  SORT AGGREGATE        |       |     1 |     8 |            |          |
|*  2 |   HASH JOIN            |       |  1000 |  8000 |     5  (20)| 00:00:01 |
|   3 |    INDEX FAST FULL SCAN| T1_PK |  1000 |  4000 |     2   (0)| 00:00:01 |
|   4 |    INDEX FAST FULL SCAN| T2_PK |  1000 |  4000 |     2   (0)| 00:00:01 |
PLAN_TABLE_OUTPUT                                                              
Predicate Information (identified by operation id):                            
   2 - access(NVL("T1"."COL1",0)=NVL("T2"."COL1",0))                           
16 rows selected.
SQL>
SQL> --verbose version of NVL
SQL> explain plan for
  2  select count(*)
  3  from t1, t2
  4  where t1.col1 = t2.col1
  5  or ( (t1.col1 is null and t2.col1 = 0) or (t2.col1 is null and t1.col1 = 0) or (t1.col1 is null and t2.col1 is null) )
  6  /
Explained.
SQL>
SQL> SELECT * FROM table(DBMS_XPLAN.DISPLAY);
PLAN_TABLE_OUTPUT                                                              
Plan hash value: 1043818223                                                    
| Id  | Operation              | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT       |       |     1 |     8 |     2   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE        |       |     1 |     8 |            |          |
|   2 |   NESTED LOOPS         |       |  1000 |  8000 |     2   (0)| 00:00:01 |
|   3 |    INDEX FAST FULL SCAN| T1_PK |  1000 |  4000 |     2   (0)| 00:00:01 |
|*  4 |    INDEX UNIQUE SCAN   | T2_PK |     1 |     4 |     0   (0)| 00:00:01 |
PLAN_TABLE_OUTPUT                                                              
Predicate Information (identified by operation id):                            
   4 - access("T1"."COL1"="T2"."COL1")                                         
16 rows selected.So if we compare the 'verbose' version of the query, in the "predicate information" section of the explain you can see that the optimizer was able to completely ignore the
or ( (t1.col1 is null and t2.col1 = 0) or (t2.col1 is null and t1.col1 = 0) or (t1.col1 is null and t2.col1 is null) ) condition since it knows that neither t1.col1 NOR t2.col1 columns can be null (by definition), and because of this we get a slightly different index access choice.