-- drop table t033 purge;
create table t033 (a not null, b not null, c not null, xxx) as 
select level, level, level, lpad('x',1000,'x') from dual connect by level <= 1e4;
create index i033_b on t033(b);
create index i033_a_b on t033(a, b);
create index i033_c on t033(c);
exec dbms_stats.gather_table_stats(user, 't033', estimate_percent => 100, cascade => true)
explain plan for select a,b,c from t033;
select * from table(dbms_xplan.display);

Plan hash value: 3894408680
 
--------------------------------------------------------------------------------------------
| Id  | Operation               | Name             | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT        |                  | 10000 |   117K|    96   (3)| 00:00:02 |
|   1 |  VIEW                   | index$_join$_001 | 10000 |   117K|    96   (3)| 00:00:02 |
|*  2 |   HASH JOIN             |                  |       |       |            |          |
|*  3 |    HASH JOIN            |                  |       |       |            |          |
|   4 |     INDEX FAST FULL SCAN| I033_B           | 10000 |   117K|    28   (0)| 00:00:01 |
|   5 |     INDEX FAST FULL SCAN| I033_A_B         | 10000 |   117K|    35   (0)| 00:00:01 |
|   6 |    INDEX FAST FULL SCAN | I033_C           | 10000 |   117K|    28   (0)| 00:00:01 |
--------------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
   2 - access(ROWID=ROWID)
   3 - access(ROWID=ROWID)

True; and this is just a general case of persuading Oracle that visiting a table many times is cheaper than visiting it once – provided the many visits don’t actually get as far as the table. I prefer use an inline view – often with a no_merge hint – to stabilise the effect in more complex examples.

Rather than setting the hidden parameter, there’s a hint (possibly not documented, though) that came up in the comments of another posting I did on the same topic.

explain plan for
select sum(b.id)
from t1 a, t1 b
where a.rowid = b.rowid
  and a.flag = 0;
select * from table(dbms_xplan.display);

------------------------------------------------------------------
| Id  | Operation              | Name    | Rows  | Bytes | Cost  |
------------------------------------------------------------------
|   0 | SELECT STATEMENT       |         |     1 |    32 |    41 |
|   1 |  SORT AGGREGATE        |         |     1 |    32 |       |
|*  2 |   HASH JOIN            |         |  5000 |   156K|    41 |
|*  3 |    INDEX RANGE SCAN    | T1_FLAG |  5000 | 75000 |    10 |
|   4 |    INDEX FAST FULL SCAN| T1_PK   |   100K|  1660K|    23 |
------------------------------------------------------------------

But from 11.2 CBO can eliminate join by rowid, and add ROWID IS NOT NULL predicate preventing consideration of IJ.
Thus without _optimizer_join_elimination_enabled = false for the same query plan will be:

-----------------------------------------------------------
| Id  | Operation          | Name | Rows  | Bytes | Cost  |
-----------------------------------------------------------
|   0 | SELECT STATEMENT   |      |     1 |    20 |   387 |
|   1 |  SORT AGGREGATE    |      |     1 |    20 |       |
|*  2 |   TABLE ACCESS FULL| T1   |  5000 |    97K|   387 |
-----------------------------------------------------------

It’s just occured to me that I’ve pointed out other bugs with the index hash join earlier http://jonathanlewis.wordpress.com/2010/11/22/index-join/ – I’m a little disappointed that I didn’t notice this one when writing CBO-Fundamentals.

Since it’s not documented my interpretation is, inevitably, a guess.
When you write a query it consists of one or more query blocks (essentially each appearance of the words select, insert, update, delete, merge, introduces a new query block). Your original query blocks appear in the outline text with the label outline(). THe optimizer then transforms the query, possibly in many different ways, to see which cost-based query transformation gives it the best plan. The transformation mechanism may result in a completely different set of query blocks being the things ultimately optimised – these query blocks appear with the lable outline_leaf().

I see you’ve worked out why your results didn’t match mine.
Your CPU costing values have kicked in, giving the full scan and fast full scans much higher prices, and just tipping your example into the table scan.
The most significant comparison, of course, is between the simple fast full scan and fast full scan as it appears in the join.

Thnks, you’re right.
Now corrected.