Re: Bitmap index - first look

Could you please put more comments on the index build procedure?

I guess it strongly relies on the fact the block number increases as tuples
are returned from "heap scan", doesn't it? However, thanks to synchronized
scans the order of tuples could be a little bit different.

I found no evidence of "build index" being able to add tid # 10 after it
has created the bitmap for tids 1000...2000. As far as I understand it never
tries to update words that were written during index creation.

That particular "if (_blockno != buf->hot_buffer_block) {" in
buf_add_tid_with_fill looks to be a wrong thing for me -- I believe it is a
way to often (it will try to sync the buffer after each 300/8=~40 bytes
since there are no more than 300 tuples on a single page)
I would not flush the bitmap every data block, but I would keep "hot buffer"
as a temporary view (uncompressed) of the bitmap being build. So as tuples
come, we either set the bit directry in the "hot buffer" (if it covers the
relevant tid range) or flush that view to the bitmap (merging, and splitting
the bitmap where it is required) and repoint the window so it starts with
block of tid that triggered flushing. Does that make sense?

Regards,
Vladimir Sitnikov