Re: Trying to reduce per tuple overhead (bitmap) - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Trying to reduce per tuple overhead (bitmap)
Date
Msg-id 200206022208.g52M8ku10342@candle.pha.pa.us
Whole thread Raw
In response to Trying to reduce per tuple overhead (bitmap)  (Manfred Koizar <mkoi-pg@aon.at>)
List pgsql-hackers
Manfred Koizar wrote:
> Tom Lane wrote in another tread:
> > PS: I did like your point about BITMAPLEN; I think that might be
> > a free savings.  I was waiting for you to bring it up on hackers
> > before commenting though...
> So here we go...
> 
> Hi,
> 
> in htup.h MinHeapTupleBitmapSize is defined to be 32,  i.e. the bitmap
> uses at least so many bits, if the tuple has at least one null
> attribute.  The bitmap starts at offset 31 in the tuple header.  The
> macro BITMAPLEN calculates, for a given number of attributes NATTS,
> the length of the bitmap in bytes.  BITMAPLEN is the smallest number n
> divisible by 4, so that 8*n >= NATTS.
> 
> The size of the tuple header is rounded up to a multiple of 4 (on a
> typical(?) architecture) by MAXALIGN(...).  So we get:
> 
> NATTS  BITMAPLEN  THSIZE
>   8        4        36
>  16        4        36
>  33        8        40
> 
> I don't quite understand the definition of BITMAPLEN:
> 
> #define BITMAPLEN(NATTS) \
>    ((((((int)(NATTS) - 1) >> 3) + 4 - (MinHeapTupleBitmapSize >> 3)) \
>     & ~03) + (MinHeapTupleBitmapSize >> 3))

Thanks for improving this.  I had to look at this macro recently and it
was quite confusing.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [BUGS] Bug #655: win32 client and bytea column
Next
From: Bruce Momjian
Date:
Subject: Re: Compilation failed when --with-recode specified (patch)