Re: Question regarding the database page layout. - Mailing list pgsql-hackers

From Ryan Bradetich
Subject Re: Question regarding the database page layout.
Date
Msg-id e739902b0808110822m4cf5483bw1582239d67eefd30@mail.gmail.com
Whole thread Raw
In response to Re: Question regarding the database page layout.  (Gregory Stark <stark@enterprisedb.com>)
List pgsql-hackers
Hello Greg,

On Mon, Aug 11, 2008 at 2:24 AM, Gregory Stark <stark@enterprisedb.com> wrote:
"Ryan Bradetich" <rbradetich@gmail.com> writes:

> After a cursory glance at the HeapTupleHeaderData structure, it appears it
> could be aligned with INTALIGN instead of MAXALIGN. The one structure I was
> worried about was the 6 byte t_ctid structure. The comments in
> src/include/storage/itemptr.h file indicate the ItemPointerData structure is
> composed of 3 int16 fields. So everthing in the HeapTupleHeaderData
> structure is 32-bits or less.

Sure, but the tuple itself could contain something with double alignment. If
you have a bigint or double in the tuple then heap_form_tuple needs to know
where to put it so it ends up at right alignment.

My first thought was we can still figure this out because the user data is already
forced to be MAXALIGN.   Then I realized oh, since that is true then I am still going
to eat the padding anyhow.  The padding would just move to one of two places:
    1. To MAXALIGN the user data or
    2. To MAXALIGN the heap tuple header.

Thanks for the sanity check.  I was wrapped up in looking for alignment requirements
in the HeapTupleHeaderData structure, I overlooked the significance of the MAXALIGN
on the user data.

Thanks,

- Ryan

P.S.  Just for the archive, it seems this idea still may be workable (need to look at the
heap_form_tuple in significant more detail) if/when someone implements the proposal
to separate the physical storage from the column order.   That solution is a bit more
than I am ready to tackle at the moment :)  Maybe in the future.

pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: proposal: UTF8 to_ascii function
Next
From: "Pavel Stehule"
Date:
Subject: Re: proposal: UTF8 to_ascii function