Hi,
How are you doing with the bitmap indexes?
I've been trying to get my head around the patch a couple of times to
add the vacuum support, but no matter how simple I try to keep it, I
just always seem to get stuck.
It looks like vacuum support would need:
- something similar to read_words, let's call it iterate_set_bits, that
returns each set bit from a bitmap vector, keeping the buffer locked
over calls.
- ability to clear the bit returned by iterate_set_bits. If normal index
scans also used this, the same functions could be used to support the
kill_prior_tuple thingie.
The above also needs to be able to recompress a page if it gets
fragmented by repeated setting and clearing of bits.
I still feel that the data structures are unnecessarily complex. In
particular, I'd like to get rid of the special-cased last_word and
last_comp_word in the lov item. Perhaps we could instead embed a normal,
but smaller, BMBitmapData structure in the lov item, and just add a
length field to that?
You have a lot of code to support efficient building of a bitmap index.
I know you've worked hard on that, but do we really need all that? How
did the bitmap build work in the previous versions of the patch, and how
much faster is the current approach?
BTW: It occured to me that since we're piggybacking on b-tree's strategy
numbers, comparison operators etc, conceivably we could also use any
other indexam. For example, a bitmap GiST would be pretty funky. We'll
probably leave that for future versions, but have you given that any
thought?
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
