Re: Bitmap index - first look

>> Additional heap contains unique values and page's number with offset
>> number in bitmap index, b-tree index contains tuples with the same values
>> and ItemPointer to heap's row. So, heap is an unnecessary step - b-tree
>> index should store ItemPointer to the bitmap index directly.
> B-tree points to LOVItem (heap's row) because the LOVItem contains
> some vector metadata, plus the last two words of the actual bitmap
> vector, last_compword and last_word; they are stored there because
> they will be changing in most cases.

I'm talking about pg_bitmapindex.pg_bm_OID tables - they contain distinct values
from indexed table and pair of (blockNumber, offsetNumber), which is exactly
ItemPointerData. I suppose, that pair points somewhere in bitmap index. In other
hand, tuple of index 'pg_bitmapindex.pg_bm_OID_idx' contains the same distinct
values and ItemPointer pointed to row in corresponding pg_bitmapindex.pg_bm_OID
table.

Why doesn't ItemPointer in pg_bitmapindex.pg_bm_OID_idx point into bitmap index
file?

Actually, you don't need a pg_bitmapindex.pg_bm_OID tables at all - the same
data could be stored in pg_bitmapindex.pg_bm_OID_idx itself. But this is not a
strong objection, just an a optimization.

BTW, see comments near index_getnext():
* Note: caller must check scan->xs_recheck, and perform rechecking of the
* scan keys if required. We do not do that here because we don't have
* enough information to do it efficiently in the general case.

Although it's not true for b-tree now, but it may change.

--
Teodor Sigaev E-mail: teodor(at)sigaev(dot)ru
WWW: http://www.sigaev.ru/