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?
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.
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.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
