>Mark Kirkwood wrote
> > Tom Lane wrote:
> >
> >I believe that the term "bitmap index" is also used with a different
> >meaning wherein it actually does describe a particular kind of on-disk
> >index structure, with one bit per table row.
> >
> >IMHO building in-memory bitmaps (the first idea) is a very good idea to
> >pursue for Postgres. I'm not at all sold on on-disk bitmap indexes,
> >though ... those I suspect *are* sufficiently replaced by partial
> >indexes.
> >
Well, if we could cache the bitmap after it was created the first time then
that might offer almost the same thing..... :-)
I was thinking about this recently, then realised that building the bitmap
would not be as easily, since PostgreSQL doesn't index null values. That
would mean that the sets of CTIDs in each index would be disjoint. My
thinking about dynamic bitmaps came from Teradata, which does index null
values.
How would you dynamically build the bit maps from the indexes?
Or would you:
- copy aside and sort the indexes on CTID
- merge join them all to find matching CTIDs
- probe into the main table
Hopefully, I've missed something that you've thought of !
> I believe that the benefit of on-disk bitmap indexes is supposed to be
> reduced storage size (compared to btree).
>
> In the cases where I have put them to use, they certainly occupy
> considerably less disk than a comparable btree index - provided there
> are not too many district values in the indexed column.
>
The main problem is the need for the table to be read-only. Until we have
partitioning, we wouldn't be able to easily guarantee parts of a table as
being (effectively) read-only.
