Question regarding the database page layout. - Mailing list pgsql-hackers
From | Ryan Bradetich |
---|---|
Subject | Question regarding the database page layout. |
Date | |
Msg-id | e739902b0808110107j76320e95m1babda71833b4ff3@mail.gmail.com Whole thread Raw |
Responses |
Re: Question regarding the database page layout.
|
List | pgsql-hackers |
<div dir="ltr">Hello all,<br /><br />I have been digging into the database page layout (specifically the tuples) to ensurethe unsigned integer types were consuming the proper storage.<br />While digging around, I found one thing surprising: <br /><br />It appears the heap tuples are padded at the end to the MAXALIGN distance.<br /><br />Below is mydata that I used to come to this conclusion.<br />(This test was performed on a 64-bit system with --with-blocksize=32).<br/><br /> The goal was to compare data from comparable type sizes. <br />The first column indicatesthe type (char, uint1, int2, uint2, int4, and uint4),<br />the number in () indicates the number of columns in thetable. <br /><br />The Length is from the .lp_off field in the ItemId structure.<br /> The Offset is from the .lp_lenfield in the ItemId structure.<br />The Size is the offset difference.<br /><br />char (1) Length Offset Size char (9) Length Offset Size<br /> 25 32736 32 33 32728 40<br /> 25 32704 32 33 32688 40<br /> 25 32672 32 33 32648 40<br /> 25 32640 33 32608 <br /> <br />uint1 (1) Length Offset Size uint1 (9) Length Offset Size<br /> 25 32736 32 33 32728 40<br /> 25 32704 32 33 32688 40<br /> 25 32672 32 33 32648 40<br /> 25 32640 33 32608 <br /> <br />int2 (1) Length Offset Size int2 (5) Length Offset Size<br /> 26 32736 32 34 32728 40<br /> 26 32704 32 34 32688 40<br /> 26 32672 32 34 32648 40<br /> 26 32640 34 32608 <br /> <br />uint2 (1) Length Offset Size unt2 (5) Length Offset Size<br /> 26 32736 32 34 32728 40<br /> 26 32704 32 34 32688 40<br /> 26 32672 32 34 32648 40<br /> 26 32640 34 32608 <br /> <br />int4 (1) Length Offset Size int4 (3) Length Offset Size<br /> 28 32736 32 36 32728 40<br /> 28 32704 32 36 32688 40<br /> 28 32672 32 36 32648 40<br /> 28 32640 36 32608 <br /> <br />uint4 (1) Length Offset Size uint4 (3) Length Offset Size<br /> 28 32736 32 36 32728 40<br /> 28 32704 32 36 32688 40<br /> 28 32672 32 36 32648 40<br /> 28 32640 36 32608 <br /><br />From the documentation at: <a href="http://www.postgresql.org/docs/8.3/static/storage-page-layout.html">http://www.postgresql.org/docs/8.3/static/storage-page-layout.html</a><br />andfrom the comments in src/include/access/htup.h I understand the user data (indicated by t_hoff) <br /> must by a multipleof MAXALIGN distance, but I did not find anything suggesting the heap tuple itself <br />had this requirement.<br/><br />After a cursory glance at the HeapTupleHeaderData structure, it appears it could be aligned with<br/>INTALIGN instead of MAXALIGN. The one structure I was worried about was the 6 byte t_ctid <br />structure. Thecomments in src/include/storage/itemptr.h file indicate the ItemPointerData structure<br /> is composed of 3 int16 fields. So everthing in the HeapTupleHeaderData structure is 32-bits or less.<br /><br />I am interested in attempting togenerate a patch if this idea appears feasible. The current data<br />set I am playing with it would save over 3GB ofdisk space. (Back of the envelope calculations <br /> indicate that 5% of my current storage is consumed by this padding. My tuple length is 44 bytes.)<br /><br />Thanks,<br /><br />- Ryan<br /></div>
pgsql-hackers by date: