Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005

CHAPTER 11 ■ INDEXES 449
Table 11-7. Representation of a Bitwise OR
Value/Row 1 2 3 4 5 6 7 8 9 10 11 12 13 14
CLERK 1 0 0 0 0 0 0 0 0 0 1 1 0 1
MANAGER 0 0 0 1 0 1 1 0 0 0 0 0 0 0
CLERK or 1 0 0 1 0 1 1 0 0 0 1 1 0 1
MANAGER
Table 11-7 rapidly shows us that rows 1, 4, 6, 7, 11, 12, and 14 satisfy our criteria. The
bitmap Oracle stores with each key value is set up so that each position represents a rowid in
the underlying table, if we need to actually retrieve the row for further processing. Queries
such as the following:
select count(*) from emp where job = 'CLERK' or job = 'MANAGER'
will be answered directly from the bitmap index. A query such as this:
select * from emp where job = 'CLERK' or job = 'MANAGER'
on the other hand, will need to get to the table. Here, Oracle will apply a function to turn the
fact that the i’th bit is on in a bitmap, into a rowid that can be used to access the table.
When Should You Use a Bitmap Index?
Bitmap indexes are most appropriate on low distinct cardinality data (i.e., data with relatively
few discrete values when compared to the cardinality of the entire set). It is not really possible
to put a value on this—in other words, it is difficult to define what low distinct cardinality truly
is. In a set of a couple thousand records, 2 would be low distinct cardinality, but 2 would not
be low distinct cardinality in a two-row table. In a table of tens or hundreds of millions
records, 100,000 could be low distinct cardinality. So, low distinct cardinality is relative to the
size of the resultset. This is data where the number of distinct items in the set of rows divided
by the number of rows is a small number (near zero). For example, a GENDER column might
take on the values M, F, and NULL. If you have a table with 20,000 employee records in it, then
you would find that 3/20000 = 0.00015. Likewise, 100,000 unique values out of 10,000,000
results in a ratio of 0.01—again, very small. These columns would be candidates for bitmap
indexes. They probably would not be candidates for a having B*Tree indexes, as each of the
values would tend to retrieve an extremely large percentage of the table. B*Tree indexes
should be selective in general, as outlined earlier. Bitmap indexes should not be selective—
on the contrary, they should be very “unselective” in general.
Bitmap indexes are extremely useful in environments where you have lots of ad hoc
queries, especially queries that reference many columns in an ad hoc fashion or produce
aggregations such as COUNT. For example, suppose you have a large table with three columns:
GENDER, LOCATION, and AGE_GROUP. In this table, GENDER has a value of M or F, LOCATION can take
on the values 1 through 50, and AGE_GROUP is a code representing 18 and under, 19-25, 26-30,
31-40, and 41 and over. You have to support a large number of ad hoc queries that take the
following form: