when I executed the query in 11.2.0.1.0 the query returning rows..

SQL> SELECT /*+ */
  2    "T1"."C1" "C1",
  3    "T1"."C2" "C2",
  4    "T1"."PADDING" "PADDING"
  5  FROM
  6    (SELECT /*+ */ DISTINCT
  7       ROWNUM "RN"
  8     FROM
  9        "T2") "VW_NSO_2",
 10     "T1"
 11  WHERE
 12    "VW_NSO_2"."RN"=ROWNUM;

Execution Plan
----------------------------------------------------------
Plan hash value: 1330072140

--------------------------------------------------------------------------------
| Id  | Operation               | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------
|   0 | SELECT STATEMENT        |      |   100M|  4196M|   125K  (1)| 00:25:09 |
|   1 |  COUNT                  |      |       |       |            |          |
|*  2 |   FILTER                |      |       |       |            |          |
|   3 |    MERGE JOIN CARTESIAN |      |   100M|  4196M|   125K  (1)| 00:25:09 |
|   4 |     VIEW                |      | 10000 |   126K|    15   (7)| 00:00:01 |
|   5 |      HASH UNIQUE        |      | 10000 |       |    15   (7)| 00:00:01 |
|   6 |       COUNT             |      |       |       |            |          |
|   7 |        TABLE ACCESS FULL| T2   | 10000 |       |    14   (0)| 00:00:01 |
|   8 |     BUFFER SORT         |      | 10000 |   302K|   125K  (1)| 00:25:09 |
|   9 |      TABLE ACCESS FULL  | T1   | 10000 |   302K|    13   (8)| 00:00:01 |
--------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - filter("VW_NSO_2"."RN"=ROWNUM)

Note
-----
   - dynamic sampling used for this statement (level=2)

I am rechecking the test case… i will update you soon

SELECT /*+ */
  "T1"."C1" "C1",
  "T1"."C2" "C2",
  "T1"."PADDING" "PADDING"
FROM
  (SELECT /*+ */ DISTINCT
     ROWNUM "RN"
   FROM
     "TESTUSER"."T2" "T2") "VW_NSO_2",
  "TESTUSER"."T1" "T1"
WHERE
  "VW_NSO_2"."RN"=ROWNUM

I suspect that the above is failing because ROWNUM at that point should have been undefined (similar to NULL). Also interesting is to see that the execution plan generated by a DBMS_XPLAN, pulling the execution plan from memory, is a bit different from the output of AUTOTRACE:

SQL_ID  4kk2gag8fs4jt, child number 0
-------------------------------------
SELECT T1.* FROM T1 WHERE     ROWNUM IN (      SELECT        ROWNUM RN      
FROM        T2)
 
Plan hash value: 881956856
 
----------------------------------------------------------------------------------------
| Id  | Operation             | Name | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
----------------------------------------------------------------------------------------
|   1 |  COUNT                |      |      1 |        |      0 |00:00:00.03 |      49 |
|*  2 |   FILTER              |      |      1 |        |      0 |00:00:00.03 |      49 |
|   3 |    TABLE ACCESS FULL  | T1   |      0 |  10000 |      0 |00:00:00.01 |       0 |
|*  4 |    FILTER             |      |      1 |        |      0 |00:00:00.03 |      49 |
|   5 |     COUNT             |      |      1 |        |  10000 |00:00:00.02 |      49 |
|   6 |      TABLE ACCESS FULL| T2   |      1 |      1 |  10000 |00:00:00.01 |      49 |
----------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - filter( IS NOT NULL)
   4 - filter(ROWNUM=ROWNUM)

Notice that the filter predicate for plan ID 2 no longer shows “2 – filter( EXISTS (???)”, but instead shows “2 – filter( IS NOT NULL)”, which I believe means that no rows can be returned. Adding a NO_QUERY_TRANSFORMATION hint does not alter the generated execution plan.

Now, repeat the test on Oracle Database 11.1.0.7. AUTOTRACE outputs an execution plan that looks like this:

Execution Plan
----------------------------------------------------------
Plan hash value: 881956856

------------------------------------------------------------------------------
| Id  | Operation             | Name | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------
|   0 | SELECT STATEMENT      |      |   100M|  2574M|    10   (0)| 00:00:01 |
|   1 |  COUNT                |      |       |       |            |          |
|*  2 |   FILTER              |      |       |       |            |          |
|   3 |    TABLE ACCESS FULL  | T1   | 10000 |   263K|     8   (0)| 00:00:01 |
|*  4 |    FILTER             |      |       |       |            |          |
|   5 |     COUNT             |      |       |       |            |          |
|   6 |      TABLE ACCESS FULL| T2   |     1 |       |     2   (0)| 00:00:01 |
------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------
   2 - filter( EXISTS (<not feasible>)
   4 - filter(ROWNUM=ROWNUM)

The filter predicate “2 – filter( EXISTS (???)” that had appeared in the output from 10.2.0.2 changed to “2 – filter( EXISTS ()” . The DBMS_XPLAN output looks like this on 11.1.0.7 (same as 10.2.0.2):

SQL_ID  6ywscwr5ambz0, child number 0
-------------------------------------
SELECT /*+ */ T1.* FROM T1 WHERE     ROWNUM IN (      SELECT        
ROWNUM RN      FROM        T2)
 
Plan hash value: 881956856
 
----------------------------------------------------------------------------------------
| Id  | Operation             | Name | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT      |      |      1 |        |      0 |00:00:00.01 |      49 |
|   1 |  COUNT                |      |      1 |        |      0 |00:00:00.01 |      49 |
|*  2 |   FILTER              |      |      1 |        |      0 |00:00:00.01 |      49 |
|   3 |    TABLE ACCESS FULL  | T1   |      0 |  10000 |      0 |00:00:00.01 |       0 |
|*  4 |    FILTER             |      |      1 |        |      0 |00:00:00.01 |      49 |
|   5 |     COUNT             |      |      1 |        |  10000 |00:00:00.01 |      49 |
|   6 |      TABLE ACCESS FULL| T2   |      1 |      1 |  10000 |00:00:00.01 |      49 |
----------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - filter( IS NOT NULL)
   4 - filter(ROWNUM=ROWNUM)

I think that we have to keep in mind that ROWNUM does not have a value (is NULL?) until the result row source is generated, and any equality comparison with a NULL is false.

If someone else has a better explanation – please feel free to post a comment.

Edit: I just noticed that the <not feasible> did not display in the filter predicates.

It was very nice interesting concept/demo you have put forward to discuss. I have gone through the demo which you stated across, perhaps in the example you have utilized across the “EXISTS” operator across T1 and T2 and results in zero rows. If check basic thing, rownum does assigns the rowvalue numeric value for the rows which get satisfies the “where” criteria of segment and it that satisfies then results into number assigned to Rownum. Looking into that concept the rownum=rownum does results into zero rows (Optimizer does have statistics and expected to scan 10000 rows and it does – good thing we need to understand the where clause or filter predicate on which rownum purely depends on). If you consider the other test cases of In and inline view, the columns/rows apart from rownum does return and satisfies the criteria.
let me know your comments.. too !!

Partially related old news to this article, ROWNUM can lead to poor execution plans in Oracle Database release versions prior to 11.2.0.1:
http://hoopercharles.wordpress.com/2009/12/09/sql-%e2%80%93-bad-execution-plan-caused-by-rownum-row_number-is-possible-fix/

So, queries having WHERE ROWNUM < 5 000 000 000 would actually return wrong results (only 4 Billion rows are returned, then the COUNT STOPKEY rowsource silently bails out):

http://blog.tanelpoder.com/2010/10/25/count-stopkey-operation-the-where-rownum/

Not that this is relevant to everyday operations, but I discovered this when moving tens of billions of rows onto an Exadata cluster…