From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Ryan Bradetich" <rbradetich(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Question regarding the database page layout. |
Date: | 2008-09-02 17:02:04 |
Message-ID: | 15742.1220374924@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Ryan Bradetich" <rbradetich(at)gmail(dot)com> writes:
> On Tue, Sep 2, 2008 at 8:07 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> It's conceivable that we could make this work if we wanted to dedicate
>> an infomask bit to showing whether the tuple needs int or double
>> alignment. I don't really think it's worth the trouble though.
> I am not sure what an infomask bit is yet, but is it safe to assume
> (in theory) that if I get the
> page written correctly, that the tuple reading code would work because
> of the t_hoff field?
Well, as Greg pointed out, setting t_hoff correctly should be sufficient
for squeezing out useless padding between the tuple header and the tuple
data. The real objection here is that that's leaving most of the
possible gain still on the table. The tuple *as a whole* (header and
data both) is still going to get maxaligned when it's plopped onto a
disk page. I think that in real-world cases that's often where the
main padding cost comes in: with 23-byte tuple headers and no OIDs,
you aren't saving a thing by int-aligning t_hoff unless you have a nulls
bitmap and it's the wrong number of bytes long.
So IMHO the real problem is over near PageAddItem.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2008-09-02 17:12:28 | Re: Window functions patch v04 for the September commit fest |
Previous Message | Gregory Stark | 2008-09-02 16:54:56 | Re: Question regarding the database page layout. |