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