Re: Optimization of the alignment padding

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: ITAGAKI Takahiro <itagaki(dot)takahiro(at)lab(dot)ntt(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Optimization of the alignment padding
Date: 2005-11-09 18:24:11
Message-ID: 17870.1131560651@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)commandprompt(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2005-11-09 18:24:27 Re: compiling on windows with mingw
Previous Message Robert Creager 2005-11-09 16:54:49 Re: SIGSEGV taken on 8.1 during dump/reload