True, Oracle does not perform full scan with such a dummy condition which allways results in FALSE. This is also an example how one could be misled in guessing what Oracle will perform by just reading the explain plan. Here is a very simple demonstration.

Let us see what Oracle is telling us what it will do with a simple query, first without a dummy FALSE condition and secondly with it:

SQL> SET AUTOTRACE TRACEONLY EXPLAIN
SQL> SELECT * FROM SCOTT.EMP;

Execution Plan
----------------------------------------------------------
--0------SELECT STATEMENT Optimizer=CHOOSE
--1----0---TABLE ACCESS (FULL) OF 'EMP'

SQL> SELECT * FROM SCOTT.EMP WHERE 1=0;

Execution Plan
----------------------------------------------------------
--0-----SELECT STATEMENT Optimizer=CHOOSE
--1----0---FILTER
--2----1-----TABLE ACCESS (FULL) OF 'EMP'

We can see that in both example Oracle is telling us it will perform full table scan, and in the case with dummy FALSE condition it will apply an extra filter condition to each fetched row. This implies the dummy FALSE condition might have bad impact on performance on a large table. But let us now see what Oracle realy does by looking at statistics of both cases. Pay attention on values of logical and physical I/O (db block gets, consistent gets, physical reads):

SQL> SET AUTOTRACE TRACEONLY STATISTICS
SQL> SELECT * FROM SCOTT.EMP;

14 rows selected.


Statistics
----------------------------------------------------------
0 recursive calls
4 db block gets
2 consistent gets
0 physical reads
0 redo size
2716 bytes sent via SQL*Net to client
659 bytes received via SQL*Net from client
8 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
14 rows processed

SQL> SELECT * FROM SCOTT.EMP WHERE 1=2;

no rows selected


Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
0 consistent gets
0 physical reads
0 redo size
1277 bytes sent via SQL*Net to client
558 bytes received via SQL*Net from client
6 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
0 rows processed

We can see that in first case it realy performed a table scan, but in second case with dummy FALSE condition it didn't perform a single I/O operation! So in fact the table scan never took place in second example, although the explain plan tels us so. The truth is Oracle's optimizer is clever enough not to perform a query where WHERE condition always results in FALSE regardles of data contents. It is the same with dummy TRUE condition, although this is not so easy to proof as with FALSE. So the fact is that such dummy condition do not harm the performance at all.