Could you please put more comments on the index build procedure?<br /><br />I guess it strongly relies on the fact the
blocknumber increases as tuples are returned from "heap scan", doesn't it? However, thanks to synchronized scans the
orderof tuples could be a little bit different.<br /><br />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
werewritten during index creation.<br /><br />That particular "if (_blockno != buf->hot_buffer_block) {" in
buf_add_tid_with_filllooks to be a wrong thing for me -- I believe it is a way to often (it will try to sync the buffer
aftereach 300/8=~40 bytes since there are no more than 300 tuples on a single page)<br /> I would not flush the bitmap
everydata block, but I would keep "hot buffer" as a temporary view (uncompressed) of the bitmap being build. So as
tuplescome, we either set the bit directry in the "hot buffer" (if it covers the relevant tid range) or flush that view
tothe bitmap (merging, and splitting the bitmap where it is required) and repoint the window so it starts with block of
tidthat triggered flushing. Does that make sense?<br /><br /><br />Regards,<br />Vladimir Sitnikov<br />