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

"Ryan Bradetich" <rbradetich@gmail.com> writes:

> Hello Greg,
>
> On Tue, Sep 2, 2008 at 8:30 AM, Gregory Stark <stark@enterprisedb.com> wrote:
>>
>> But I'm confused. You seem to be tweaking the alignment of the data inside the
>> tuple? After the tuple header? I thought we had only one byte of wasted space
>> in there and that's used by the null bitmap. So unless you have more than 8
>> columns and some of them are null I wouldn't expect you to save any space. If
>> you do then I guess you could save 4 bytes if the null bitmap is 2-5 bytes
>> (mod 8) long.
>
> I was not trying to tweak the alignment of the data inside the tuple header,
> I was trying to adjust the alignment of t_hoff so it would not have the
> requirement of MAXALIGN. I believe my proof-of-concept patch was bad and I
> need to spend some more time on it tonight with the new knowledge I gained
> from this email thread.

The structure on the page is to have a bunch of tuples stored one after the
other. Each tuple is maxaligned after the previous (actually before the
previous since they start from the end but we'll ignore that -- the point is
that they all *start* at a maxaligned position on the page).

Within each tuple there's a header which is 23 bytes long. Then an optional
null bitmap. In the header is t_hoff which points to the first byte of actual
data -- effectively specifying the length of the null bitmap. t_hoff is
maxaligned as well.

So by intaligning t_hoff you're adjusting where the data within the tuple fits
by making the null bitmap 4 bytes shorter. That seems worth a few cycles but
isn't going to affect every table. It'll only affect tables that have a null
bitmap between 2-5 bytes (mod 8), ie, with 9-40 fields at least one of which
is null. Tables with 9 fields are likely to be relatively wide which means
saving 4 bytes isn't that much of a gain percentagewise. (Though they might be
mostly null....) 

The other 4 bytes you could save is by packing the whole tuples themselves
more closely on the page. That happens when the item pointer is added and
pointed to the tuple. To do that heap_form_tuple would have to return data
back to the caller about the alignment needed to whomever is going to copy it
into the page. AFAICS that could be done in the HeapTuple structure itself
rather than in the tuple though which doesn't seem so bad. Tom may be seeing
something I'm not though.

Incidentally, can't you set the alignment during the compute_data_size() call
instead of doing an extra pass through the attributes? Probably doesn't change
the cost though.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services!