On 9/19/06 5:15 AM, "Gavin Sherry" <[EMAIL PROTECTED]> wrote:
> On Tue, 19 Sep 2006, Heikki Linnakangas wrote: > >> Jie Zhang wrote: >>> Hi Heikki and all, >>> >>> Please find the latest bitmap index patch in the attachment. This patch is >>> generated against the postgresql cvs head. >>> >> >> Thanks. >> >> The handling of stream and hash bitmaps looks pretty complicated to me. >> All the bitmap-related nodes have logic to handle both types slightly >> differently. It all seems to come down to that if a subnode (or >> amgetbitmap in a bitmap index scan node) returns a StreamBitmap, the >> caller needs to call the subnode many times, until it returns a NULL. >> With a HashBitmap, the caller only calls the subnode once. >> >> I think amgetbitmap should be called just once per index scan, and it >> should return either a hash bitmap or a stream bitmap. The same applies >> to all the executor nodes that return bitmaps, they would only return a >> single HashBitmap or StreamBitmap, and the upper node would call >> tbm_iterate repeatedly on that. >> >> StreamBitmap would contain a callback (filled by the indexam) that >> tbm_iterate would call to fill the next TBMIterateResult. > > Right, this was the approach taken by an earlier version of the patch I > had worked on. It was significantly uglified by the need to keep the index > state around and to be careful about what amrescan might do behind out > back. I will, however, introduce the idea again because it makes the code > much cleaner and more logical, as you seem to suggest. I will think about this approach. But I am not quite convinced that this approach will be simpler and cleaner than the above approach. :-) Thanks, Jie ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly