Thanks for the explanation. I agree that there are cases where the bitmap index size grows unexpectedly. The moral of the story is that one has to use the bitmap index with more care than with the B-tree index.

Another unexpected behavior of the bitmap index is that it spends very little time in I/O when answering a query. I have not seen many people talking about this, probably because people can not get into the system. To get to the guts of the system, we implemented our own version of the bitmap indexes. In theory, ORACLE’s bitmap index is a BBC compressed basic bitmap index. To make sure our implementation is up to par, we performed extensive tests and results show that our implementation generally use about the same amount of space and are about twice as fast in answering queries. Next, we measure the time spent in I/O as a fraction of the total time used to answer a query in our own system. The results are documented in this report at DOLAP 2002, and a summary is shown in this picture. Even on a ridiculously slow disk system with 2 MB/s throughput, BBC compressed indexes may use as little as 50% of total time on I/O. Note that this measurement is done with unmounting the file system after each query, therefore the I/O time is the longest possible. In a typical system, the file system is mounted already and disk system are much faster than 2MB/s. The I/O time would be even smaller fraction of the total query response time. The moral of this story, smaller bitmap indexes are not always faster!

Thanks for the comment.

The statement proposed as Myth 1 says that bitmap indexes are bigger than B*tree indexes, and my first comment about this is that we usually hear exactly the opposite, i.e. that it’s the B*tree indexes that are usually the larger indexes – and that’s exactly what I said in comment 13.

In the main body of the blog, I pointed out that bitmap indexes can grow dramatically if the underlying table is subject to certain types of DML – and then demonstrated this.

Your comment, however, has drawn my attention to the fact that my closing statement on that myth was badly put ‘So the “myth” has been mis-quoted, and it’s not a myth.’ and I’ve rewritten it to avoid the ambiguity.

Your comment 13 seems to be saying that Bitmap Indexes are indeed smaller than B-Tree indexes, which is opposite of what you stated as Myth 1. In the main body of the blog, you seem to be arguing that Myth 1 is true. What gives?

You could do some damage limitations by using index compression – any columns that were good candidates for bitmap indexes will probably compress quite well.