Oracle rownum wrong explain plan

Question

SCOTT@oracle10g>create table t as select * from dba_objects;
Table created.
SCOTT@oracle10g>alter table t modify CREATED date not null;
Table altered.
SCOTT@oracle10g>insert into t select * from t;
50416 rows created.
SCOTT@oracle10g>insert into t select * from t;
100832 rows created.
SCOTT@oracle10g>insert into t select * from t;
201664 rows created.
SCOTT@oracle10g>commit;
Commit complete.
SCOTT@oracle10g>create index t_created on t(created) nologging;
Index created.
SCOTT@oracle10g>select * from v$version;
BANNER
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - Prod
PL/SQL Release 10.2.0.3.0 - Production
CORE    10.2.0.3.0      Production
TNS for 32-bit Windows: Version 10.2.0.3.0 - Production
NLSRTL Version 10.2.0.3.0 - Production
SCOTT@oracle10g>set autot trace
SCOTT@oracle10g>select t.owner,t.object_name   from
  2  (select rid from (
  3  select rownum rn,rid from
  4  (select rowid rid from t order by created)
  5  where rownum<100035)
  6  where rn>100000) h, t
  7  where t.rowid=h.rid;
34 rows selected.
Execution Plan
Plan hash value: 3449471415
| Id  | Operation           | Name      | Rows  | Bytes |TempSpc| Cost (%CPU)| T
ime     |
|   0 | SELECT STATEMENT    |           |   100K|    11M|       |  4776   (2)| 0
0:00:58 |
|*  1 |  HASH JOIN          |           |   100K|    11M|  3616K|  4776   (2)| 0
0:00:58 |
|*  2 |   VIEW              |           |   100K|  2442K|       |  1116   (2)| 0
0:00:14 |
|*  3 |    COUNT STOPKEY    |           |       |       |       |            |
        |
|   4 |     VIEW            |           |   440K|  5157K|       |  1116   (2)| 0
0:00:14 |
|   5 |      INDEX FULL SCAN| T_CREATED |   440K|  9024K|       |  1116   (2)| 0
0:00:14 |
|   6 |   TABLE ACCESS FULL | T         |   440K|    39M|       |  1237   (2)| 0
0:00:15 |
Predicate Information (identified by operation id):
   1 - access("T".ROWID="RID")
   2 - filter("RN">100000)
   3 - filter(ROWNUM<100035)
Note
   - dynamic sampling used for this statement
Statistics
          0  recursive calls
          0  db block gets
       5814  consistent gets
          0  physical reads
          0  redo size
       1588  bytes sent via SQL*Net to client
        422  bytes received via SQL*Net from client
          4  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
         34  rows processed   
here ,oracle don't choose the best explain plan ,I think becase  oracle compute cadinality 100k ,so it don't choose nest loop,why oracle can't compute cardinality 35 here ??
|*  2 |   VIEW              |           |   100K|  2442K|       |  1116   (2)| 0
SCOTT@oracle10g>select  t.owner,t.object_name   from t where rowid in
  2      (select rid from (
  3      select rownum rn,rid from
  4      (select rowid rid from t order by created)
  5      where rownum<100035)
  6      where rn>100000)
  7 
SCOTT@oracle10g>/
34 rows selected.
Execution Plan
Plan hash value: 1566335206
| Id  | Operation                   | Name      | Rows  | Bytes | Cost (%CPU)| T
ime     |
|   0 | SELECT STATEMENT            |           |     1 |   107 |  1586   (2)| 0
0:00:20 |
|   1 |  NESTED LOOPS               |           |     1 |   107 |  1586   (2)| 0
0:00:20 |
|   2 |   VIEW                      | VW_NSO_1  |   100K|  1172K|  1116   (2)| 0
0:00:14 |
|   3 |    HASH UNIQUE              |           |     1 |  2442K|            |
        |
|*  4 |     VIEW                    |           |   100K|  2442K|  1116   (2)| 0
0:00:14 |
|*  5 |      COUNT STOPKEY          |           |       |       |            |
        |
|   6 |       VIEW                  |           |   440K|  5157K|  1116   (2)| 0
0:00:14 |
|   7 |        INDEX FULL SCAN      | T_CREATED |   440K|  9024K|  1116   (2)| 0
0:00:14 |
|   8 |   TABLE ACCESS BY USER ROWID| T         |     1 |    95 |     1   (0)| 0
0:00:01 |
Predicate Information (identified by operation id):
   4 - filter("RN">100000)
   5 - filter(ROWNUM<100035)
Note
   - dynamic sampling used for this statement
Statistics
          0  recursive calls
          0  db block gets
        301  consistent gets
          0  physical reads
          0  redo size
       1896  bytes sent via SQL*Net to client
        422  bytes received via SQL*Net from client
          4  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
         34  rows processed
SCOTT@oracle10g>select /*+ordered use_nl(t)*/ t.owner,t.object_name   from
  2  (select rid from (
  3  select rownum rn,rid from
  4  (select rowid rid from t order by created)
  5  where rownum<100035)
  6  where rn>100000) h, t
  7  where t.rowid=h.rid;
34 rows selected.
Execution Plan
Plan hash value: 3976541160
| Id  | Operation                   | Name      | Rows  | Bytes | Cost (%CPU)| T
ime     |
|   0 | SELECT STATEMENT            |           |   100K|    11M|   101K  (1)| 0
0:20:16 |
|   1 |  NESTED LOOPS               |           |   100K|    11M|   101K  (1)| 0
0:20:16 |
|*  2 |   VIEW                      |           |   100K|  2442K|  1116   (2)| 0
0:00:14 |
|*  3 |    COUNT STOPKEY            |           |       |       |            |
        |
|   4 |     VIEW                    |           |   440K|  5157K|  1116   (2)| 0
0:00:14 |
|   5 |      INDEX FULL SCAN        | T_CREATED |   440K|  9024K|  1116   (2)| 0
0:00:14 |
|   6 |   TABLE ACCESS BY USER ROWID| T         |     1 |    95 |     1   (0)| 0
0:00:01 |
Predicate Information (identified by operation id):
   2 - filter("RN">100000)
   3 - filter(ROWNUM<100035)
Note
   - dynamic sampling used for this statement
Statistics
          0  recursive calls
          0  db block gets
        304  consistent gets
          0  physical reads
          0  redo size
       1588  bytes sent via SQL*Net to client
        422  bytes received via SQL*Net from client
          4  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
         34  rows processed  

Answer 1

jinyu wrote:
Thanks for your great reply and posting ,could you tell me why subquery has the least cost here ??
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 107 | 1586 (2)| 00:00:20 |
| 1 | NESTED LOOPS | | 1 | 107 | 1586 (2)| 00:00:20 |
| 2 | VIEW | VW_NSO_1 | 100K| 1172K| 1116 (2)| 00:00:14 |
| 3 | HASH UNIQUE | | 1 | 2442K| | |
|* 4 | VIEW | | 100K| 2442K| 1116 (2)| 00:00:14 |
|* 5 | COUNT STOPKEY | | | | | |
| 6 | VIEW | | 440K| 5157K| 1116 (2)| 00:00:14 |
| 7 | INDEX FULL SCAN | T_CREATED | 440K| 9024K| 1116 (2)| 00:00:14 |
| 8 | TABLE ACCESS BY USER ROWID| T | 1 | 95 | 1 (0)| 00:00:01 |
----------------------------------------------------------------------------------------->
You'll notice that as a result of a "driving" IN subquery Oracle has done a hash unique operation (line 3) on the rowids produced by the subquery. At this point the optimizer has lost all knowledge of the number of distinct values for that data column in the subquery and come back with the cardinality of one. The re-appearance of 100K as the cardinality in line 2 is an error, but I don't think the optimizer has used that value in later arithmetic.
Given the cardinality of one, the obvious path into the T table is a nested loop.
The same type of probelm appears when you use the table() operator in joins - you can use the cardinality() hint to try an tell Oracle how many rows the table() will produce, but that doesn't tell it how many distinct values there are in join columns - and that's an important detail when you work out the join cardinality and method).
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.
"Science is more than a body of knowledge; it is a way of thinking"
Carl Sagan