Inline subquery cardinality wrong, execution path not correct

Question

hi:
i have a simple query , I just can not get the execution path correct. please advice .
SELECT *
FROM fcst_budget a,
SELECT *
FROM fcst_root_facility_all
WHERE salesman IN (200)
) b
WHERE a.ci=b.ci AND a.facility=b.facility
Plan
SELECT STATEMENT ALL_ROWSCost: 2,276 Bytes: 1,317,411 Cardinality: 1,593
3 HASH JOIN Cost: 2,276 Bytes: 1,317,411 Cardinality: 1,593
1 INDEX FAST FULL SCAN INDEX (UNIQUE) SALES.FCST_ROOT_FACILITY_ALL_PK Cost: 1,466 Bytes: 331,660 Cardinality: 515
2 TABLE ACCESS FULL TABLE SALES.FCST_BUDGET Cost: 807 Bytes: 27,628,425 Cardinality: 150,975
fcst_root_facility_all has 50K records, with index on salesman, pk = ci,facility
fcst_budget has 150K records, pk= ci,facility,yr_prd
the problem is it is always doing full table scan for fcst_budget, which is not what I am looking for.
the inline subquery output is only 80 records with unique ci and facility and the desired execution plan will be using inline
subquery as driving table to nested loop join the fcst_budget table, the pk for fcst_budget should be used.
Somehow, this just does not happen.
I tried to create a intermediate temp table to stage teh inline subquery result, and the result is good.
DROP TABLE aaa
CREATE TABLE aaa
AS
SELECT *
FROM fcst_root_facility_all
WHERE salesman IN (200)
SELECT *
FROM fcst_budget a,
aaa b
WHERE a.ci=b.ci AND a.facility=b.facility
Plan
SELECT STATEMENT ALL_ROWSCost: 193 Bytes: 937,890 Cardinality: 102
4 NESTED LOOPS Cost: 193 Bytes: 937,890 Cardinality: 102
1 TABLE ACCESS FULL TABLE SALES.AAA Cost: 4 Bytes: 720,960 Cardinality: 80
3 TABLE ACCESS BY INDEX ROWID TABLE SALES.FCST_BUDGET Cost: 3 Bytes: 183 Cardinality: 1
2 INDEX RANGE SCAN INDEX (UNIQUE) SALES.FCST_BUDGET_PK Cost: 2 Cardinality: 1
comparing two plans, you can see the first plan step1, the cardinality=515, which is actually should be 80 in this case.
Any body can help me tune this query to make Oracle optimizer pickup the correct plan?
I do not like the temp table solution case it decreases the scalability.
thanks

Answer 1

SamB:
Neither the /*+ cardinality (c 80) */ nor the USE_NL works.
I also regenerated historgrams, that did not help either.
Oracle is so persistent to use its own decision no matter what I tell it to do.
The amazing thing I found today after tried your hint is:
I re-analyze the fcst_root_facility_all table using DBMS_STATS.GATHER_TABLE_STATS
function, and magically, it worked.
I used to use analyze command to analyze table, seems there is some important accuracy difference between the two.
although still can not understand why some many hint does not work, I am OK for now.
thanks