Heikki,
On Mon, 5 Mar 2007, Heikki Linnakangas wrote:
> Hi all,
>
> I'd like to see the indexam API changes needed by the bitmap indexam to
> be committed soon. Has anyone looked at the proposed API in the latest
> patch? Any thoughts?
Thanks for looking at it!
>
> I'm quite happy with it myself, with a few reservations:
>
> - All the getbitmap implementations except the new bitmap indexam are
> just boilerplate. How about making getbitmap-function optional, and
> having a generic implementation that fills in a hash bitmap using the
> traditional getnext function?
>
> - getbitmap is passed an existing bitmap as argument, and the
> implementation needs to OR the existing bitmap with new tuples. How
> about AND? An indexam could be smart about ANDing with an existing
> bitmap, for example skipping to the first set bit in the existing bitmap
> and starting the scan from there.
>
> - I'd like to have support to return candidate matches with both
> getbitmap and getnext. A simple flag per page of results would be enough
> for getbitmap, I think.
>
> - StreamBitmap and HashBitmap are separate node types, but OpStream is
> not. opaque-field in the StreamBitmap struct is not really that opaque,
> it needs to be a StreamNode. I drew a UML sketch of what I think the
> class-hierarchy is
> (http://community.enterprisedb.com/streambitmaps.png). This is
> object-oriented programming, we're just implementing classes and
> inheritance with structs and function pointers. The current patch mixes
> different techniques, and that needs to be cleaned up.
All good ideas, I'll look at them more closely in the morning.
> I'd like to see a separate patch that contains just the API changes.
> Gavin, could you extract an API-only patch from the bitmap index patch?
> I can work on it as well, but I don't want to step on your toes.
Okay, I can do that.
Thanks,
Gavin
.){kind=link}