Re: [PATCHES] WIP: bitmap indexes

On 8/17/06 5:54 AM, "Tom Lane"  wrote:

> "Jie Zhang"  writes:
>> 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.
> 
> No, I'm assuming the other proposal that was on the table, namely to get
> rid of amgetmulti in its current form and instead have an AM call that
> delivers a bitmap in one step.  (Probably should rename the pg_am column
> to something like amgetbitmap.)  nodeBitmapIndexscan would become pretty
> trivial.  For the existing AMs this just means that they call
> tbm_add_tuple(s) for themselves, which is no big problem, especially
> considering that they probably get to save some code by not having to
> stop the indexscan when the buffer array gets full.

This sounds good. Another problem is about ScalarArrayOpExpr support in
current nodeBitmapIndexscan. This will not work for stream bitmaps. We have
to disable it in the optimizer.

Thanks,
Jie