Re: Trying to reduce per tuple overhead - Mailing list pgsql-novice

From Rasmus Mohr
Subject Re: Trying to reduce per tuple overhead
Date
Msg-id 910513A5A944D5118BE900C04F67CB5A0BFD89@MAIL
Whole thread Raw
In response to Trying to reduce per tuple overhead  (Manfred Koizar <mkoi-pg@aon.at>)
List pgsql-novice
That question doesn't really belong to the the novice list, does it? ;-)

--------------------------------------------------------------
Rasmus T. Mohr            Direct  :             +45 36 910 122
Application Developer     Mobile  :             +45 28 731 827
Netpointers Intl. ApS     Phone   :             +45 70 117 117
Vestergade 18 B           Fax     :             +45 70 115 115
1456 Copenhagen K         Email   : mailto:rmo@netpointers.com
Denmark                   Website : http://www.netpointers.com

"Remember that there are no bugs, only undocumented features."
--------------------------------------------------------------

> -----Original Message-----
> From: pgsql-novice-owner@postgresql.org
> [mailto:pgsql-novice-owner@postgresql.org]On Behalf Of Manfred Koizar
> Sent: Thursday, May 02, 2002 11:23 AM
> To: pgsql-novice@postgresql.org
> Subject: [NOVICE] Trying to reduce per tuple overhead
>
>
> 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))
>
> AFAICS only for MinHeapTupleBitmapSize == 32 we get a meaningful
> result, namely a multiple of MinHeapTupleBitmapSize, converted from a
> number of bits to a number of bytes.  If this is true, we dont't need
> the "+ 4 - (MinHeapTupleBitmapSize >> 3)" and the definition could be
> simplified to
>     (((((int)(NATTS) - 1) >> 3) & ~03) + 4)
>
> Some examples, writing MBMB for (MinHeapTupleBitmapSize >> 3):
>
> MBMB = 4:
> ((((NATTS - 1) >> 3) + 4 - MBMB) & ~03) + MBMB
>     32     31     3    7     3      0       4
>     33     32     4    8     4      4       8
>     64     63     7   11     7      4       8
>     65     64     8   12     8      8      12
>
> MBMB = 1:
> ((((NATTS - 1) >> 3) + 4 - MBMB) & ~03) + MBMB
>      8      7     0    4     3      0       1
>      9      8     1    5     4      4       5
>     32     31     3    7     6      4       5
>     33     32     4    8     7      4       5
>     56     55     6   10     9      8       9
>     64     63     7   11    10      8       9
>     65     64     8   12    11      8       9
>
> MBMB = 8:
> ((((NATTS - 1) >> 3) + 4 - MBMB) & ~03) + MBMB
>      8      7     0    4    -4     -4       4
>      9      8     1    5    -3     -4       4
>     32     31     3    7    -1     -4       4
>     33     32     4    8     0      0       8
>     56     55     6   10     2      0       8
>     64     63     7   11     3      0       8
>     65     64     8   12     4      4      12
>
> Proposal 1:
> #define BitMapBytes 4    // or any other power of 2
> #define MinHeapTupleBitmapSize (BitMapBytes * 8)
> #define BITMAPLEN(NATTS) \
>   (((((int)(NATTS) - 1) >> 3) & ~(BitMapBytes - 1)) + BitMapBytes)
>
> 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?
>
> Servus
>  Manfred
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>
>

pgsql-novice by date:

Previous
From: Manfred Koizar
Date:
Subject: Trying to reduce per tuple overhead
Next
From: Terrence Brannon
Date:
Subject: non-root installation of Postgresql?