Re: Question regarding the database page layout.
От | Ryan Bradetich |
---|---|
Тема | Re: Question regarding the database page layout. |
Дата | |
Msg-id | e739902b0809020932p25de62d3i2ad518db8b3c6085@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Question regarding the database page layout. (Gregory Stark <stark@enterprisedb.com>) |
Ответы |
Re: Question regarding the database page layout.
|
Список | pgsql-hackers |
Hello Greg, On Tue, Sep 2, 2008 at 8:30 AM, Gregory Stark <stark@enterprisedb.com> wrote: > "Ryan Bradetich" <rbradetich@gmail.com> writes: > >> 4. If require_max_align = true, use the MAXALIGN macro; otherwise >> use the INTALIGN macro. > > Huh, I didn't think of doing it like that. > > 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. > I thought the goal was to save space by aligning the tuples on the page more > densely. That seems to me to be more fruitful as about half the tuples will > save four bytes even on tables with small or missing null bitmaps. That is the goal. Basically my test data is 44 bytes in length for each tuple. I have no data in the tuple that is required to be MAXALIGN, but since t_hoff has the MAXALIGN requirement I throw away 4 bytes for each tuple (on a 64-bit machine). This proof-of-concept patch is to help me understand the PostgreSQL code and to see if I can recover those 4 bytes per tuple. Thanks again for your feedback! - Ryan
В списке pgsql-hackers по дате отправления: