Re: Bitmap index status
От | Gavin Sherry |
---|---|
Тема | Re: Bitmap index status |
Дата | |
Msg-id | Pine.LNX.4.58.0609192213040.20965@linuxworld.com.au обсуждение исходный текст |
Ответ на | Re: Bitmap index status (Heikki Linnakangas <heikki@enterprisedb.com>) |
Ответы |
Re: Bitmap index status
Re: Bitmap index status |
Список | pgsql-hackers |
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. Thanks, Gavin
В списке pgsql-hackers по дате отправления: