Chris Browne <cbbrowne@xxxxxxx> 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
