Re: [PATCHES] WIP: bitmap indexes

> It occurs to me that what tbm_begin_iterate really is is a constructor
> for a stream bitmap object that reads out the contents of a tbm bitmap
> (we need a decent name for the non-stream data structure ... maybe
> hash bitmap?). If we think of it like that then we can unify the
> ideas some more.
>
> My proposal at this point would be to invent two different Node types,
> one for stream bitmaps and one for hash bitmaps. The initial input to
> nodeBitmapHeapscan can be either, but if it's given a hash bitmap then
> it stream-ifies it for use. amgetmulti can return either kind, and
> nodeBitmapAnd and nodeBitmapOr can use IsA tests to decide what to do.
> Preserving the existing optimization for ORing hash bitmaps is a bit
> tricky but I think it's doable. Consider this API for amgetmulti:
>
> amgetmulti takes an argument which can be either a hash bitmap or NULL.
> It returns an object that must be either a hash or stream bitmap.
> If it wants to return a stream bitmap, it simply disregards the argument
> and returns a constructed stream-bitmap object. If it wants to return
> a hash bitmap, then if the argument is not NULL, OR the additional bits
> into the argument object and return it; if the argument is NULL,
> construct a fresh hash-bitmap object, set bits in it, and return it.

This sounds great. One thing I am concern about is that this will add the
dependency of node types into the access methods. If we still keep
nodeBitmapIndexscan and let it do the bitmap construction for tids returned
by amgetmulti.

Otherwise, I think that I get a pretty good picture about how to do this.

Thanks,
Jie