In general, bitmap indexes are very useful in data warehouse systems, and the most dramatic benefit you get from bitmap indexes appears when Oracle combines multiple bitmap indexes (which are often just single column indexes) to reduce the visits to table blocks to the smallest necessary set.

In this case, though, it’s unfortunate that there is an “obvious” optimisation that should apply when you do a bitmap index join that simply hasn’t been allowed for in the optimizer code.

Bear in mind, though, that the query you’re looking at would have to visit every row (hence block) in the table if the bitmap indexes weren’t there – so you’re not using bitmap indexes in the “standard” way of avoid unnecessary visits to table blocks, so you’ve just been a bit unlucky at the edges of the code when you combine bitmap indexes, partitioned tables, and count(*) optimisation.

I only asked this question in previous thread. Table size 35gb and bitmap index size on SRC_SYS,PROD_KEY are below 40mb. If i created btree indexes then it would be around 1gb size. while reading documents about tuning DWH systems, it said having individual bitmap indexes on columns, those indexes can participate in Bitmap AND/OR operation and will do much better than the btree indexes for adhoc queries which has multiple column on the predicates.

I thought of instead of scanning 35 gb table / scanning btree indexes of 1GB on this column, create bitmap indexes and joining of 35 mb bitmap index with 40 mb bitmap index would be better than the above.

But running this query, with Full table scan plan, finishes faster than the above plan. FTS plan, did not take this much of sort area.
Bitmap join plan, converting into rowids took around 3Gig sort and took a long time.

Is have bitmap indexes on DWH fact tables will not be benefitted on bitmap AND/OR operation?

Of course your plan proposed would be ideal since it could run the main HASH UNIQUE operation as part of the partition-wise operation, but since according to the original trace the main problem is the HASH JOIN, not the HASH UNIQUE, I think turning the HASH JOIN into a partition-wise join would eliminate most of the excess work.

I’ve did a quick test with a manual re-write of an index join as you’ve proposed in your series about index joins and managed to arrive at a plan that does a partition-wise index join based on the two bitmap indexes and a single HASH UNIQUE operation on top of that. It’s not the plan you’ve proposed (since it does not a splitted HASH UNIQUE with one as part of the partition-wise operation) but I think solves the main problem described here.

Simple index join without any other operation does not make use of partition-wise operations:

---------------------------------------------------------------------------
| Id  | Operation                      | Name             | Pstart| Pstop |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT               |                  |       |       |
|   1 |  VIEW                          | index$_join$_001 |       |       |
|*  2 |   HASH JOIN                    |                  |       |       |
|   3 |    PARTITION LIST ALL          |                  |     1 |     4 |
|   4 |     BITMAP CONVERSION TO ROWIDS|                  |       |       |
|   5 |      BITMAP INDEX FULL SCAN    | T_BIDX1          |     1 |     4 |
|   6 |    PARTITION LIST ALL          |                  |     1 |     4 |
|   7 |     BITMAP CONVERSION TO ROWIDS|                  |       |       |
|   8 |      BITMAP INDEX FULL SCAN    | T_BIDX2          |     1 |     4 |
---------------------------------------------------------------------------

The plan I’ve arrived at:

---------------------------------------------------------------------
| Id  | Operation                         | Name    | Pstart| Pstop |
---------------------------------------------------------------------
|   0 | SELECT STATEMENT                  |         |       |       |
|   1 |  SORT AGGREGATE                   |         |       |       |
|   2 |   VIEW                            |         |       |       |
|   3 |    HASH UNIQUE                    |         |       |       |
|   4 |     PARTITION LIST ALL            |         |     1 |     4 |
|*  5 |      HASH JOIN                    |         |       |       |
|   6 |       BITMAP CONVERSION TO ROWIDS |         |       |       |
|   7 |        BITMAP INDEX FAST FULL SCAN| T_BIDX4 |     1 |     4 |
|   8 |       BITMAP CONVERSION TO ROWIDS |         |       |       |
|   9 |        BITMAP INDEX FAST FULL SCAN| T_BIDX3 |     1 |     4 |
---------------------------------------------------------------------

It required however the bitmap indexes to include the partition key (and use it as part of the join condition in addition to the ROWID) which is certainly a nuisance.

Randolf

It is a pity that Oracle doesn’t support this (yet) for above partition-wise join case.

Although not the same as what you’ve proposed and not with the same efficiency, it would be interesting to see the plan when requesting parallel execution, something like

select count(1) from (select /*+ parallel_index(REV_F) index_join(REV_F REV_F_IDX1 REV_F_IDX5) */ distinct SRC_SYS,PROD_KEY from dds.REV_F);

It will probably still suffer from the same problem, but at least it will very likely show two levels of HASH UNIQUE operations (although not at the coordinator level, so I’m not entirely sure if it is the same as described above for the MAX() case), so it comes at least closer to your proposal.

Randolf