BITMAP indexes ignored with large IN(...)

Question

I have a fact table with 20 million records joined to a few dimension tables using 10g BITMAP INDEXes but if I add more than two or three items to my SELECT query the optimizer does not choose to use the bitmaps. For example, the first query
SELECT p.period_date, po.agent_id, count(*), SUM(ah.charge_amt)
FROM Travel_History ah, Period p, Agent po
WHERE ah.primary_agent_key = po.agent_key
AND ah.period_key = p.period_key
AND po.agent_id IN( 'DGF ', '001MG ' )
AND p.period_date =
TO_DATE( '20010701', 'YYYYMMDD' )
AND p.period_date =
TO_DATE( '20010801', 'YYYYMMDD' )
GROUP BY po.agent_id, p.period_date
definitely uses my BITMAPs as I see that in my EXECUTION PLAN (i.e. I have set autotrace on):
| 0 | SELECT STATEMENT | | 1 | 32
| 1 | HASH GROUP BY | | 1 | 32
|* 2 | FILTER | | |
| 3 | NESTED LOOPS | | 1 | 32
|* 4 | HASH JOIN | | 1 | 19
|* 5 | TABLE ACCESS FULL | PERIOD | 1 | 10
| 6 | TABLE ACCESS BY INDEX ROWID | TRAVEL_HISTORY | 4000K| 34
| 7 | BITMAP CONVERSION TO ROWIDS | | |
| 8 | BITMAP AND | | |
| 9 | BITMAP OR | | |
|* 10 | BITMAP INDEX SINGLE VALUE| XIF4TRAVEL_HISTORY | |
|* 11 | BITMAP INDEX SINGLE VALUE| XIF4TRAVEL_HISTORY | |
| 12 | BITMAP MERGE | | |
|* 13 | BITMAP INDEX RANGE SCAN | TRVLHIST_MULTI3_BMIX | |
|* 14 | BITMAP INDEX SINGLE VALUE | XIF1TRAVEL_HISTORY | |
|* 15 | TABLE ACCESS BY INDEX ROWID | AGENT | 1 | 13
|* 16 | INDEX UNIQUE SCAN | XPKAGENT | 1 |
There are only a few hundred records for those two dates, and the above query returns in
less than a second.
However, if I replace the two "period_date =" with IN(...) as:
SELECT /*+ INDEX_COMBINE( Travel_history
AcctHist_MULTI3_bmix
XIF4TRAVEL_HISTORY
XIF1TRAVEL_HISTORY )
p.period_date, po.agent_id, count(*), SUM(ah.charge_amt)
FROM Travel_History ah, Period p, Agent po
WHERE ah.primary_agent_key = po.agent_key
AND ah.period_key = p.period_key
AND po.agent_id IN( 'DGF ', '001MG ' )
AND p.period_date IN (
TO_DATE( '20010701', 'YYYYMMDD' ),
TO_DATE( '20010801', 'YYYYMMDD' ) )
GROUP BY po.agent_id, p.period_date
the execution plan goes back to
| 0 | SELECT STATEMENT | | 747 | 23904 | 45760 (7)|
| 1 | HASH GROUP BY | | 747 | 23904 | 45760 (7)|
|* 2 | FILTER | | | | |
|* 3 | HASH JOIN | | 5000K| 152M| 44897 (5)|
| 4 | MERGE JOIN CARTESIAN| | 860 | 19780 | 26 (0)|
|* 5 | TABLE ACCESS FULL | PERIOD | 4 | 40 | 6 (0)|
| 6 | BUFFER SORT | | 215 | 2795 | 20 (0)|
| 7 | TABLE ACCESS FULL | AGENT | 215 | 2795 | 5 (0)|
| 8 | TABLE ACCESS FULL | TRAVEL_HISTORY | 20M| 171M| 44527 (4)|
If I do a UNION with two SELECTs each with a unique period then the BITMAPs get used. I don't get it.
Is there any reason this would be happening???

Answer 1

There are no bitmap indexes, there is a 64k tablespace header block containing the bitmap of occupied and free extents.
Sybrand Bakker
Senior Oracle DBA