Re: Question regarding the database page layout.
От | Ryan Bradetich |
---|---|
Тема | Re: Question regarding the database page layout. |
Дата | |
Msg-id | e739902b0809020925g4a920291nf22a7ee6c77dd411@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Question regarding the database page layout. (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Question regarding the database page layout.
|
Список | pgsql-hackers |
Hello Tom, On Tue, Sep 2, 2008 at 8:07 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > "Ryan Bradetich" <rbradetich@gmail.com> 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. Ifthe 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
В списке pgsql-hackers по дате отправления: