Re: plans for bitmap indexes?

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Updated TODO:
>
> > * Allow the creation of bitmap indexes which can be quickly combined
> > with other bitmap indexes
>
> This TODO item description is fundamentally misleading.
>
> The point was *not* about making "bitmap indexes", which on its face
> suggests a persistent on-disk data structure comparable to our existing
> index types. The point was about using transient in-memory bitmaps as
> an interface between the on-disk indexes and accessing the table proper.

There are two separate issues --- on-disk bitmap indexes and on-the-fly
in-memory created ones. I tried to mention both but obviously it wasn't
clear. Here is new wording:

* Allow non-bitmap indexes to be combined by creating bitmaps in memory

Bitmap indexes index single columns that can be combined with other bitmap
indexes to dynamically create a composite index to match a specific query.
Each index is a bitmap, and the bitmaps are bitwise AND'ed or OR'ed to be
combined. They can index by tid or can be lossy requiring a scan of the
heap page to find matching rows.

* Allow the creation of on-disk bitmap indexes which can be quickly
combined with other bitmap indexes

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073