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.  (Gregory Stark <stark@enterprisedb.com>)
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:

Previous
From: "Heikki Linnakangas"
Date:
Subject: Re: Proposal: PageLayout footprint
Next
From: "Heikki Linnakangas"
Date:
Subject: Re: gsoc, oprrest function for text search take 2