Re: Question regarding the database page layout.

From: "Ryan Bradetich" <rbradetich(at)gmail(dot)com>
To: "Gregory Stark" <stark(at)enterprisedb(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Question regarding the database page layout.
Date: 2008-09-02 21:51:07
Message-ID: e739902b0809021451j2c99c7a4h5991663278e7450@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello Greg,

On Tue, Sep 2, 2008 at 9:54 AM, Gregory Stark <stark(at)enterprisedb(dot)com> wrote:
> "Ryan Bradetich" <rbradetich(at)gmail(dot)com> writes:
> 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.

Thanks for your persistence in explaining this issue to me. I think I
am starting
to understand the issues now and I appreciate the help.

I think I see the error in my thinking. You and Tom are saying the tuple is
MAXALIGN on the page as well. My assumption was that since t_hoff had to be
MAXALIGN, the tuple on the page was being MAXALIGN by default. If I
was able to
INTALIGNt_hoff then the tuple on the page would be free to be INTALIGN as well.

Tom gave me the next place to go look later tonight (PageAddItem).

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

Actually I did not do an extra pass through the attributes. I added
the check in an
existing pass through the attributes. I did look at adding this check to the
heap_compute_data_size(), but took the easy path to see if my patch
worked. I will
update my patch to do the alignment check in heap_compute_data_size().

Thanks!

- Ryan

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ryan Bradetich 2008-09-02 21:52:43 Re: Question regarding the database page layout.
Previous Message Brian Hurt 2008-09-02 21:47:49 Feature request: better debug messages