From: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
---|---|
To: | Gavin Sherry <swm(at)alcove(dot)com(dot)au> |
Cc: | pgsql-patches(at)postgresql(dot)org |
Subject: | Re: Updated bitmap index patch |
Date: | 2007-03-12 13:39:06 |
Message-ID: | 45F557FA.4060403@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-03-12 14:36:50 | Re: Bitmapscan changes |
Previous Message | Teodor Sigaev | 2007-03-12 13:35:24 | Re: Updated bitmap index patch |