Re: Optimization of the alignment padding - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Optimization of the alignment padding
Date
Msg-id 17870.1131560651@sss.pgh.pa.us
Whole thread Raw
In response to Re: Optimization of the alignment padding  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: Optimization of the alignment padding  (ITAGAKI Takahiro <itagaki.takahiro@lab.ntt.co.jp>)
List pgsql-hackers
Alvaro Herrera <alvherre@commandprompt.com> writes:
> There was a discussion during the 8.1 devel cycle about shortening the
> HeapTupleHeader struct.  It involved some games with the command Ids.
> Maybe you'll want to look at that, as it could have an impact on what
> you're trying to do here.

It would, in fact, largely eliminate the point of this patch, since the
standard header size would go back to being a multiple of 8.

I believe the patch is a bad idea as proposed, even if it works at all
(have you tested it on machines that enforce alignment?)  The reason is
that if the start of the tuple data area isn't necessarily at a MAXALIGN
boundary, then the internal padding within the tuple depends on what
alignment the start was at --- consider the case where a double-aligned
field follows some fields that have lesser alignment.  This is going to
vastly complicate matters, because it will not be possible to lay out
the tuple contents without first figuring out exactly what the header looks
like --- ie, whether there's a null bitmap (and how long the bitmap is),
whether there's an OID, and so on.  It will probably actually break some
places, because I think we sometimes attach a data area to a separately
created header.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Robert Creager
Date:
Subject: Re: SIGSEGV taken on 8.1 during dump/reload
Next
From: "Kevin Grittner"
Date:
Subject: Re: compiling on windows with mingw