Considering the following in the OP’s email:
* The execution plans were (apparently, but not necessarily) the same
* The FIRST_ROWS hinted version of the query completed 24 seconds faster (1.79 times faster) than then FIRST_ROWS(100) hinted version of the query
* The calculated cost of FIRST_ROWS hinted version of the query is 8591 times greater than the calculated cost of the FIRST_ROWS(100) hinted version of the query

I think that it is safe to say that the FIRST_ROWS hint (and optimizer mode) does not cause something magic to happen in the database instance, where 8591 times as much work is accomplished in 55.86% of the amount of time – just in case someone was confused, and attempting to tune by the calculated cost that appears in execution plans.

Regards

Martin

Thanks for noticing and pointing out the costing difference between the FIRST_ROWS and FIRST_ROWS(100) – sorry for the delayed response (and thanks for finding the related article). I repeated your test case and obtained similar results on Oracle Database 11.2.0.2:

SET AUTOTRACE TRACEONLY EXPLAIN
 
select /*+ first_rows */ * from test_first_rows_hint;
 
Execution Plan
----------------------------------------------------------
Plan hash value: 3818872010
 
------------------------------------------------------------------------------------------
| Id  | Operation         | Name                 | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |                      |  1000K|  4882K|   427   (1)| 00:00:06 |
|   1 |  TABLE ACCESS FULL| TEST_FIRST_ROWS_HINT |  1000K|  4882K|   427   (1)| 00:00:06 |
------------------------------------------------------------------------------------------

Then I went through the sequence of FIRST_ROW(n) hints:

select /*+ first_rows(1) */ * from test_first_rows_hint;

These are my results:
- first_rows: 427 (same as without a hint)
- first_rows(1): 2
- first_rows(1000): 2
- first_rows(10000): 6
- first_rows(100000): 44
- first_rows(500000): 216

Now let’s add an index into the test case to see what happens:

CREATE INDEX IND_TEST_FIRST ON TEST_FIRST_ROWS_HINT(ID);
 
EXEC DBMS_STATS.GATHER_TABLE_STATS(OWNNAME=>USER, TABNAME=>'TEST_FIRST_ROWS_HINT', CASCADE=>TRUE, ESTIMATE_PERCENT=>100)

Making a small modification to add a WHERE clause:

select * from test_first_rows_hint WHERE ID<=500000;
  
Execution Plan
----------------------------------------------------------
Plan hash value: 3818872010
 
------------------------------------------------------------------------------------------
| Id  | Operation         | Name                 | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |                      |   500K|  2441K|   429   (2)| 00:00:06 |
|*  1 |  TABLE ACCESS FULL| TEST_FIRST_ROWS_HINT |   500K|  2441K|   429   (2)| 00:00:06 |
------------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
   1 - filter("ID"<=500000)

Interestingly, the cost of the unhinted plan increased by 2 after adding the index – a minor change, but still something that is interesting.

Let’s go through the various FIRST_ROWS and FIRST_ROWS(n) hints:

select /*+ first_rows */ * from test_first_rows_hint WHERE ID<=500000;
 
Execution Plan
----------------------------------------------------------
Plan hash value: 230930807
 
-----------------------------------------------------------------------------------
| Id  | Operation        | Name           | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------
|   0 | SELECT STATEMENT |                |   500K|  2441K|  1119   (1)| 00:00:14 |
|*  1 |  INDEX RANGE SCAN| IND_TEST_FIRST |   500K|  2441K|  1119   (1)| 00:00:14 |
-----------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
   1 - access("ID"<=500000)

- first_rows: 1119 (more than twice without a hint)
- first_rows(1): 3
- first_rows(1000): 5
- first_rows(10000): 25
- first_rows(100000): 227
- first_rows(500000): 429 (full table scan)

Note in the above that there is a bit of logic in the FIRST_ROWS(n) optimizer mode, the optimizer switched from an index range scan to a full table scan when it sensed that we *promised* to retrieve all rows in the result set. It *almost* appears that the optimizer switched based on the calculated cost of the access path.

Let’s try again, bumping up the 500,000 number to 1,000,000:

select /*+ first_rows */ * from test_first_rows_hint WHERE ID<=1000000;
  
Execution Plan
----------------------------------------------------------
Plan hash value: 230930807

-----------------------------------------------------------------------------------
| Id  | Operation        | Name           | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------
|   0 | SELECT STATEMENT |                |  1000K|  4882K|  2234   (1)| 00:00:27 |
|*  1 |  INDEX RANGE SCAN| IND_TEST_FIRST |  1000K|  4882K|  2234   (1)| 00:00:27 |
-----------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------
   1 - access("ID"<=1000000)

The above suggests that the FIRST_ROWS hint calculates the cost such that we will work all the way through the data, yet the optimizer selects the index access path even though the WHERE clause tells the optimizer that according to the statistics we will be taking all rows in the table.

- first_rows: 2234 (more than twice without a hint)
- first_rows(1): 3
- first_rows(1000): 5
- first_rows(10000): 25
- first_rows(100000): 226
- first_rows(500000): 1118 (still an index range scan)
- first_rows(1000000): 429 (full table scan)

The FIRST_ROWS(n) optimizer mode sensed that we *promised* to take only the specified number of rows. An interesting thing happened when 500000 was specified in the hint – the optimizer did not switch to a full table scan based on a cost comparison (maybe that only happens when the index contains all of the data, thus avoiding the need to directly access the table?).

Just a quick experiment:

SQL> select /*+ first_rows(999999) */ * from test_first_rows_hint WHERE ID<=1000000;
 
Execution Plan
----------------------------------------------------------
Plan hash value: 230930807
 
-----------------------------------------------------------------------------------
| Id  | Operation        | Name           | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------
|   0 | SELECT STATEMENT |                |  1000K|  4882K|  2234   (1)| 00:00:27 |
|*  1 |  INDEX RANGE SCAN| IND_TEST_FIRST |  1000K|  4882K|  2234   (1)| 00:00:27 |
-----------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
   1 - access("ID"<=1000000)

SQL> select /*+ first_rows(1000000) */ * from test_first_rows_hint WHERE ID<=1000000;
 
Execution Plan
----------------------------------------------------------
Plan hash value: 3818872010
 
------------------------------------------------------------------------------------------
| Id  | Operation         | Name                 | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |                      |  1000K|  4882K|   429   (2)| 00:00:06 |
|*  1 |  TABLE ACCESS FULL| TEST_FIRST_ROWS_HINT |  1000K|  4882K|   429   (2)| 00:00:06 |
------------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
   1 - filter("ID"<=1000000)

As shown by the above, the tipping point in this test case appears to be right at the point where the hint’s n value matches the expected number of rows to be returned.

I was a little bit surprised to see the big differences in costing for FIRST_ROWS and FIRST_ROWS(100) – it seems that FIRST_ROWS has no impact on the cost, but FIRST_ROWS(100) reduces the cost to approximately (100/number_of_rows_in_table) * initial_cost. With a simple test table I get:

create table test_first_rows_hint
as
select rownum id
  from dual
connect by level <= 1000000;

exec dbms_stats.gather_table_stats(user, 'TEST_FIRST_ROWS_HINT', estimate_percent => 100)

select * from test_first_rows_hint;

1000000 Zeilen ausgewõhlt.

Abgelaufen: 00:00:03.96

Ausf³hrungsplan
----------------------------------------------------------
Plan hash value: 3818872010

------------------------------------------------------------------------------------------
| Id  | Operation         | Name                 | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |                      |  1000K|  4882K|   780   (0)| 00:00:04 |
|   1 |  TABLE ACCESS FULL| TEST_FIRST_ROWS_HINT |  1000K|  4882K|   780   (0)| 00:00:04 |
------------------------------------------------------------------------------------------

With Hints I get the following cost results:
- first_rows: 780 (same as without a hint)
- first_rows(1): 2
- first_rows(1000): 3
- first_rows(10000): 9
- first_rows(100000): 80
- first_rows(500000): 391

After I made this simple test I found your article http://hoopercharles.wordpress.com/2011/03/10/what-is-the-difference-between-the-first_rows-hint-and-rownum-in-the-where-clause/ – seems that I missed that one…

Regards

Martin