Reduce per tuple overhead (bitmap)

Manfred Koizar <mkoi-pg@aon.at> writes:

This small patch makes the length of the null bitmap a multiple
of 1 byte (has been a multiple of 4 bytes previously), thus saving
MAXIMUM_ALIGNOF (4 or 8 on modern platforms) bytes per on-disk-tuple
in certain cases (depending on number of attributes and if there is
at least one null attribute).
Though it changes the on-disk-format, there's no need to initdb,
because data offsets are stored in t_hoff for each tuple. So this
patch can be applied to HEAD and to the 7.2 branch.

I've applied this to CVS tip. I do not think it is appropriate for
7.2 branch, however, since it's not a bug fix.

regards, tom lane

I assume this will be safe for 7.3 using 7.2 files via pg_upgrade
because those old 7.2 files will just have the longer length, right?

---------------------------------------------------------------------------

Manfred Koizar wrote:

This small patch makes the length of the null bitmap a multiple
of 1 byte (has been a multiple of 4 bytes previously), thus saving
MAXIMUM_ALIGNOF (4 or 8 on modern platforms) bytes per on-disk-tuple
in certain cases (depending on number of attributes and if there is
at least one null attribute).

It passes make check for 7.2 and for cvs HEAD.

Though it changes the on-disk-format, there's no need to initdb,
because data offsets are stored in t_hoff for each tuple. So this
patch can be applied to HEAD and to the 7.2 branch.

Servus
Manfred

diff -r -u ../orig/src/include/access/htup.h src/include/access/htup.h
--- ../orig/src/include/access/htup.h	Mon Nov  5 18:46:31 2001
+++ src/include/access/htup.h	Sun May  5 08:03:29 2002
@@ -17,7 +17,7 @@
#include "storage/bufpage.h"
#include "storage/relfilenode.h"

-#define MinHeapTupleBitmapSize	32		/* 8 * 4 */
+#define MinHeapTupleBitmapLen	1	/* in bytes, must be 2**n */

/*
* MaxHeapAttributeNumber limits the number of (user) columns in a table.
@@ -57,7 +57,7 @@

/* ^ - 31 bytes - ^ */

-	bits8		t_bits[MinHeapTupleBitmapSize / 8];
+	bits8		t_bits[MinHeapTupleBitmapLen];
/* bit map of NULLs */

/* MORE DATA FOLLOWS AT END OF STRUCT */
@@ -225,8 +225,8 @@
*		Computes minimum size of bitmap given number of domains.
*/
#define BITMAPLEN(NATTS) \
-		((((((int)(NATTS) - 1) >> 3) + 4 - (MinHeapTupleBitmapSize >> 3)) \
-		  & ~03) + (MinHeapTupleBitmapSize >> 3))
+		(((((int)(NATTS) - 1) >> 3) \
+		  & ~(MinHeapTupleBitmapLen - 1)) + MinHeapTupleBitmapLen)

/*
* HeapTupleIsValid

---------------------------(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

-- 
  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, Pennsylvania 19026

On Mon, 3 Jun 2002 00:23:46 -0400 (EDT), Bruce Momjian
<pgman@candle.pha.pa.us> wrote:

I assume this will be safe for 7.3 using 7.2 files via pg_upgrade
because those old 7.2 files will just have the longer length, right?

Bruce,

yes, I think so. And Tom Lane also seems to think so, as he has
already changed htup.h in the spirit of my patch. So there's no need
to apply it anymore.

FYI, I'm running 7.2.1 with this patch (and with the HtupAccess patch)
in real world applications. No problems so far ...

Thanks.
Servus
Manfred