Thread: Updated bitmap index patch

Hi all,

I've updated the bitmap index patch. It can be found here:

http://www.alcove.com.au/~swm/bitmap-2007-03-12.diff

This fixes some bugs introduced in the last patch, catches up to HEAD and
tidies up the executor code. I want to do a little more tidying, such as
reverting the name changes we made. multiscan still sounds alright.

I've been thinking about vacuum as well. Something along the lines of what
Heikki mentioned earlier -- namely, the ability to iterate the bitmap
setbit by setbit is in order. What I have in mind, though, is that when we
find a reaped setbit, we mark the position and continue to iterate until
we find a non reaped setbit. When, we update the underlying bitmap vector
to reflect the non-set bits.

Thoughts?

Thanks,

Gavin

I don't very like GiST changes:  gistgetbitmap will lock/unlock page for every
tuple. It seems to me taht is better to change gistnext function to use some
sort callback, for example. Or have static array for tids in gistgetbitmap...
--
Teodor Sigaev                                   E-mail: teodor@sigaev.ru
                                                    WWW: http://www.sigaev.ru/

Gavin Sherry wrote:
> Hi all,
>
> I've updated the bitmap index patch. It can be found here:
>
> http://www.alcove.com.au/~swm/bitmap-2007-03-12.diff
>
> This fixes some bugs introduced in the last patch, catches up to HEAD and
> tidies up the executor code. I want to do a little more tidying, such as
> reverting the name changes we made. multiscan still sounds alright.

Thanks, I'll take a look at it.

I just posted a patch to change the getmulti API. Please have a look at
that and say what you think. I don't want to deliberately bitrot your
patch, but on the other hand I do want to get the candidate matches
support in before the bitmap index am, because reviewing and committing
that can take a long time.

> I've been thinking about vacuum as well. Something along the lines of what
> Heikki mentioned earlier -- namely, the ability to iterate the bitmap
> setbit by setbit is in order. What I have in mind, though, is that when we
> find a reaped setbit, we mark the position and continue to iterate until
> we find a non reaped setbit. When, we update the underlying bitmap vector
> to reflect the non-set bits.

Ok. It's going to be opaque to the caller of the iterate-function
anyway, right?

--
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

Teodor,

On Mon, 12 Mar 2007, Teodor Sigaev wrote:

> I don't very like GiST changes:  gistgetbitmap will lock/unlock page for every
> tuple. It seems to me taht is better to change gistnext function to use some
> sort callback, for example. Or have static array for tids in gistgetbitmap...

Good point. I'll look at it.

Thanks

Gavin