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

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Reply via email to