LNNVL usage discussion

Question

Hiya, all
A short while ago this thread {thread:id=2441850} was posted, which triggered some thoughts...
I have never really used LNNVL much, as I generally avoid function calls on a column to be filtered in the where clause (for example never use trunc(date_column) = date '2012-09-21' ) because that precludes use of normal non-functionbased indexes.
But then LNNVL is kind of different as it is not a function on a column, but a function on a boolean expression. Maybe it was not so much a function evaluation as a shortcut method of writing something that the optimizer would understand and rewrite?
So I got curious whether the LNNVL would be evaluated like any other function call or if there was a special rewrite going on by the optimizer. I tried to do a short test:
SQL> /* create table - col1 with not null, col2 allows null */
SQL>
SQL> create table test1 (
  2     col1  integer not null
  3   , col2  integer
  4   , col3  varchar2(30)
  5  )
  6  /
Table created.
SQL>
SQL> /* insert 10000 rows with a couple nulls in col2 */
SQL>
SQL> insert into test1
  2  select rownum col1
  3       , nullif(mod(rownum,5000),0) col2
  4       , object_name col3
  5    from all_objects
  6   where rownum <= 10000
  7  /
10000 rows created.
SQL>
SQL> /* index that includes col2 null values because col1 is not null */
SQL>
SQL> create index test1_col1_col2 on test1 (
  2     col2, col1
  3  )
  4  /
Index created.
SQL>
SQL> /* gather stats */
SQL>
SQL> begin
  2     dbms_stats.gather_table_stats(USER, 'TEST1');
  3  end;
  4  /
PL/SQL procedure successfully completed.
SQL>
SQL> set autotrace on
SQL>
SQL> /* using lnnvl to select rows with col2 values 4999 and null */
SQL>
SQL> select *
  2    from test1
  3   where lnnvl(col2 <= 4998)
  4   order by col1
  5  /
      COL1       COL2 COL3
      4999       4999 DBA_LOGMNR_SESSION
      5000            DBA_LOGMNR_SESSION
      9999       4999 /69609d2d_OracleTypeHierarchy
     10000            /1cef5dbd_Oracle8TypePropertie
Execution Plan
Plan hash value: 4009883541
| Id  | Operation          | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT   |       |     1 |    27 |    17  (12)| 00:00:01 |
|   1 |  SORT ORDER BY     |       |     1 |    27 |    17  (12)| 00:00:01 |
|*  2 |   TABLE ACCESS FULL| TEST1 |     1 |    27 |    16   (7)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - filter(LNNVL("COL2"<=4998))
Statistics
          1  recursive calls
          0  db block gets
         53  consistent gets
          0  physical reads
          0  redo size
        413  bytes sent via SQL*Net to client
        364  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
          4  rows processed
SQL>
SQL> /* using or statement to select the same rows */
SQL>
SQL> select *
  2    from test1
  3   where not col2 <= 4998 or col2 is null
  4   order by col1
  5  /
      COL1       COL2 COL3
      4999       4999 DBA_LOGMNR_SESSION
      5000            DBA_LOGMNR_SESSION
      9999       4999 /69609d2d_OracleTypeHierarchy
     10000            /1cef5dbd_Oracle8TypePropertie
Execution Plan
Plan hash value: 2198096298
| Id  | Operation                     | Name            | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT              |                 |     4 |   108 |    10  (10)| 00:00:01 |
|   1 |  SORT ORDER BY                |                 |     4 |   108 |    10  (10)| 00:00:01 |
|   2 |   CONCATENATION               |                 |       |       |            |          |
|   3 |    TABLE ACCESS BY INDEX ROWID| TEST1           |     2 |    54 |     5   (0)| 00:00:01 |
|*  4 |     INDEX RANGE SCAN          | TEST1_COL1_COL2 |     2 |       |     2   (0)| 00:00:01 |
|   5 |    TABLE ACCESS BY INDEX ROWID| TEST1           |     2 |    54 |     4   (0)| 00:00:01 |
|*  6 |     INDEX RANGE SCAN          | TEST1_COL1_COL2 |     2 |       |     2   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   4 - access("COL2">4998 AND "COL2" IS NOT NULL)
   6 - access("COL2" IS NULL)
       filter(LNNVL("COL2">4998))
Statistics
          1  recursive calls
          0  db block gets
          8  consistent gets
          0  physical reads
          0  redo size
        413  bytes sent via SQL*Net to client
        364  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
          4  rows processedAs far as I understand LNNVL, this:
where lnnvl(col2 <= 4998)should be the logical equivalent of this:
where not col2 <= 4998 or col2 is nullThey do return the same rows, but using LNNVL forces evaluation of the function for all rows (full table scan), while the longer expression using OR allows the optimizer to rewrite the expression and use the index twice (because this index included a NOT NULL column.) LNNVL also gives wrong cardinality estimate while the OR way estimates spot on.
<provocative_mode>
So did I misunderstand something, or is LNNVL merely a way to allow a lazy developer to save a few keystrokes at the expense of possibly bad execution plans? ;-)
</provocative_mode>

Answer 1

Kim Berg Hansen wrote:
As far as I understand LNNVL, this:
where lnnvl(col2 <= 4998)should be the logical equivalent of this:
where not col2 <= 4998 or col2 is null
I think it is
where not col2 <= 4998 or col2 is null or 4998 is null
They do return the same rows, but using LNNVL forces evaluation of the function for all rows (full table scan), while the longer expression using OR allows the optimizer to rewrite the expression and use the index twice (because this index included a NOT NULL column.) LNNVL also gives wrong cardinality estimate while the OR way estimates spot on.
<provocative_mode>
So did I misunderstand something, or is LNNVL merely a way to allow a lazy developer to save a few keystrokes at the expense of possibly bad execution plans? ;-)
</provocative_mode>You can also say, that it is a way to confuse 95% of all pl/sql developers.