Hi Gavin,
Any progress?
Gavin Sherry wrote:
> 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
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com