Hello Tom,

On Tue, Sep 2, 2008 at 8:07 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Ryan Bradetich" <[EMAIL PROTECTED]> writes:
>> The patch concept is fairly simple.
>
>>    1.  Add a new boolean local variable: require_max_align
>> (initialized to false).
>
> This really can't possibly work, because you'd need to propagate
> knowledge of the tuple's alignment requirement all over the place.
> In particular, how would code *reading* the tuple know where the
> data starts?  Also, I don't think you get (very much of) the actual
> benefit unless the code that inserts tuples into disk pages knows
> to do something different in the int-align case.

I  figured there was something wrong with my proof-of-concept patch
because it was too easy and it passed regression tests on the first
attempt.  I just didn't know what was wrong.  After reading your comment,
I went back and looked at my test data and I am embarrassed to admit that
I misread the data :(   Sure the tuple length is 44 bytes, but the data
is still aligned on a 8 byte boundary.   So this poc patch effectively
does nothing :(

As Greg mentioned, the code reading the user data would know where
to start because of the t_hoff field.  In my first email in this thread, I had
looked at the requirements for the HeapTupleHeaderData to be MAXALIGN.
I could not find any reason the HeapTupleHeaderData needed to be MAXALIGN,
but Greg pointed out that the t_hoff filed is required to be MAXALIGN.
  I can only
see two reasons why the t_hoff field is required to be MAXALIGN:
   1. If the tuple has oids (OIDS require MAXALIGN).
   2. If the tuple has any column requiring MAXALIGN.

If neither of the above conditions are true, then it seems to me that
t_hoff could
safely be INTALIGN.   I was working under the mistaken assumption that if I
addressed this issue in heap_form_tuple, that it would be written down on disk
this way.  Obviously I was wrong and still have a lot of code reading and
experimentation to do :)

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

Thanks for your feedback!

- Ryan

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to