Chris Browne <cbbrowne@acm.org> writes:
> But to be sure, there used to be a lot of "burning interest" in
> on-disk bitmap indexes, and in-memory bitmap index scans have quenched
> many of the flames...
Well, we had in-memory bitmaps already in 8.1, and the bitmap index work
happened since that.
I think the main argument for bitmap indexes is the potential to make
the index smaller. A btree index requires a minimum of 16 bytes per
entry (20 if MAXALIGN=8), whereas a bitmap index can in principle get
down to a few bits per entry for a high-cardinality column value.
So you could hope for a 10x smaller index and corresponding reduction in
index search time.
The fly in the ointment is that if the column value is so high
cardinality as all that, it's questionable whether you want an index
search at all rather than just seqscanning; and it's definite that
the index access cost will be only a fraction of the heap access cost.
So the prospects for actual net performance gain are a lot less than
the index-size argument makes them look.
There doubtless are gains on some workloads, but how much and on how
wide a range of workloads is still an open question.
regards, tom lane
