Re: Trying to reduce per tuple overhead (bitmap)

Manfred Koizar <mkoi-pg@aon.at> writes:
> Proposal 2: Let BITMAPLEN calculate the minimum number of bytes
> necessary to have one bit for every attribute.

> #define BitMapBytes 1

>           old       old      new      new
> NATTS  BITMAPLEN  THSIZE  BITMAPLEN  THSIZE
>   8        4        36        1        32
>  16        4        36        2        36
>  33        8        40        5        36

> This looks so simple.  Is there something wrong with it?

Offhand I cannot see a reason not to change this.  There's no reason for
BITMAPLEN() to be padding the bitmap length --- every caller does its
own MAXALIGN() of the total header length, which is what we actually
need.  I suspect that BITMAPLEN's behavior is leftover from a time when
those MAXALIGN's weren't there.  But (a) this would only be helpful if
the t_bits field started on a word boundary, which it doesn't and hasn't
for a very long time; and (b) padding to a multiple of 4 is wrong
anyway, since there are machines where MAXALIGN is 8.

Since the data offset is stored in t_hoff and not recalculated on the
fly, I think that fixing BITMAPLEN is completely free from a storage
compatibility point of view; you wouldn't even need initdb.  If some
tuples have the excess padding and some do not, everything will still
work.

In short, looks good to me.  Please try it.
        regards, tom lane