Optimizer mode confusion

Question

Hello experts,
When we set optimizer mode to first_rows_100 or first_rows etc. The fetch rows doesn't change. I am trying to understand the differences between first_rows and all_rows. It gives preference to index scan against full table scan, even the index scan is no good. And also prefers nested loop over hash join. HOWEVER, except all these, please correct me if I am wrong, I do understand that first_nows_100 only fetch 100 rows regardless default fecth row, am I wrong? What do you think about the following example in terms of CONSISTENT GETS????
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> alter system flush shared_pool;
Sistem dei■tirildi.
SQL> set autotrace traceonly
SQL> select * from my_test where id < 181000;
31000 sat²rlar² seildi.
Y³r³tme Plan²
Plan hash value: 1615681525
| Id  | Operation         | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT  |         | 31001 |   605K|    53   (2)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| MY_TEST | 31001 |   605K|    53   (2)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - filter("ID"<181000)
¦statistikler
        454  recursive calls
          0  db block gets
       2323  consistent gets
         93  physical reads
        116  redo size
     843244  bytes sent via SQL*Net to client
      23245  bytes received via SQL*Net from client
       2068  SQL*Net roundtrips to/from client
          6  sorts (memory)
          0  sorts (disk)
      31000  rows processed
SQL> select * from my_test where id < 181000;
31000 sat²rlar² seildi.
Y³r³tme Plan²
Plan hash value: 1615681525
| Id  | Operation         | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT  |         | 31001 |   605K|    53   (2)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| MY_TEST | 31001 |   605K|    53   (2)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - filter("ID"<181000)
¦statistikler
          0  recursive calls
          0  db block gets
       2235  consistent gets
          0  physical reads
          0  redo size
     843244  bytes sent via SQL*Net to client
      23245  bytes received via SQL*Net from client
       2068  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
      31000  rows processed
SQL> alter session set optimizer_mode = FIRST_ROWS_100;
Oturum dei■tirildi.
SQL> select * from my_test where id < 181000;
31000 sat²rlar² seildi.
Y³r³tme Plan²
Plan hash value: 509756919
| Id  | Operation                   | Name         | Rows  | Bytes | Cost (%CPU)
| Time     |
|   0 | SELECT STATEMENT            |              |   100 |  2000 |     4   (0)
| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| MY_TEST      |   100 |  2000 |     4   (0)
| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | SYS_C0011105 |       |       |     2   (0)
| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("ID"<181000)
¦statistikler
          1  recursive calls
          0  db block gets
       4402  consistent gets
          0  physical reads
          0  redo size
    1159430  bytes sent via SQL*Net to client
      23245  bytes received via SQL*Net from client
       2068  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
      31000  rows processed
Thanks in adnvance.

Answer 1

the first_rows(n) hint is only about costing and instructs the optimizer to find a plan that returns the first n rows as fast as possible - though this approach may increase the total execution time for the query. This could be useful for applications that need only the top results most the time. Consider the following example:
drop table t;
create table t (
    col1 not null
  , col2
as
select mod(rownum, 100) col1
     , lpad('*', 50, '*') col2
  from dual
connect by level <= 100000;
exec dbms_stats.gather_table_stats(user, 'T')
create index t_idx on t(col1);
explain plan for
select *
  from t
where col1 = 1
order by col1;
select * from table(dbms_xplan.display);
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT  |      |  1000 | 54000 |   423   (0)| 00:00:03 |
|*  1 |  TABLE ACCESS FULL| T    |  1000 | 54000 |   423   (0)| 00:00:03 |
Predicate Information (identified by operation id):
   1 - filter("COL1"=1)
explain plan for
select /*+ first_rows(10) */
  from t
where col1 = 1
order by col1;
select * from table(dbms_xplan.display);
| Id  | Operation                   | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT            |       |    10 |   540 |    10   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| T     |    10 |   540 |    10   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | T_IDX |       |       |     1   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("COL1"=1)
Obiously the hint changes the costing massively - and for the given query the top 10 results could indeed be returned faster by the index scan (though the difference would be small for this small example).
The details of the costing are not that simple and they are described in Randolf Geist's presentation http://www.sqltools-plusplus.org:7676/media/FIRST_ROWS_n%20presentation%20UKOUG%202009.pdf (titled: Everything you wanted to know about first_rows_n but were afraid to ask).