[Bizgres-general] Re: Mapping from bitmap array position to heap location (was : A bitmap index access method is available...)

[Mark Kirkwood]

Jie Zhang wrote:
> 
> Current implementation sets the word size to 32-bit, which compresses each
> gap (either 65536 or 2048) into one word. So we should get the same index
> size for using 65526 or 2048 as the gap between two pages. The reason you
> get slightly bigger index with 2048, I guess, is that you use
> 
> 
>   tidoffset = ((uint64)blocknum * (MaxOffsetNumber + 1))
>                         + ((uint64)offset);
> 
> 
> Instead  of
> 
>     tidoffset = ((uint64)blocknum * (MaxOffsetNumber))
>                           + ((uint64)offset);
> 
> The former one adds one more "0" into the bitmap for each gap.
>

Right - but a 2049 gap is still much < 65526 ...(wondering if the fact 
that 2049 is not a power of 2 is important...), anyway, I will see if 
getting rid of the '+ 1' changes anything (purely out of curiosity).

> One interesting point is that you choose 2048 as max offset number. Is this
> true for all cases? If so, we can set the word size to 8-bit to further
> increase the bitmap compression rate.
> 

Not in all cases - the formula is (src/include/storage/off.h):

#define MaxOffsetNumber         ((OffsetNumber) (BLCKSZ / 
sizeof(ItemIdData)))


So it depends on your platform's alignment of ItemIdData and your choice 
of BLCKSZ. The BLCKSZ is straightforward enough, but ItemIdData is a bit 
more tricky (src/include/storage/itemid.h):

typedef struct ItemIdData
{                               /* line pointers */
     unsigned    lp_off:15,      /* offset to start of tuple */
                 lp_flags:2,     /* flags for tuple */
                 lp_len:15;      /* length of tuple */
} ItemIdData;

i.e. packed to 32 bits, which should usually be just plain old 4 bytes - 
   however, I'm not sure if this is true for odd platforms like ARM etc.

If sizeof(ItemIdData) is always *at least* 4 bytes (which seems 
reasonable) then the biggest MaxOffsetNumber can be is 32768/4 = 8192 
(i.e if you choose 32K pages).


Cheers

Mark