"Ryan Bradetich" <[EMAIL PROTECTED]> writes: > Hello Greg, > > On Tue, Sep 2, 2008 at 8:30 AM, Gregory Stark <[EMAIL PROTECTED]> wrote: >> >> 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.
The structure on the page is to have a bunch of tuples stored one after the other. Each tuple is maxaligned after the previous (actually before the previous since they start from the end but we'll ignore that -- the point is that they all *start* at a maxaligned position on the page). Within each tuple there's a header which is 23 bytes long. Then an optional null bitmap. In the header is t_hoff which points to the first byte of actual data -- effectively specifying the length of the null bitmap. t_hoff is maxaligned as well. So by intaligning t_hoff you're adjusting where the data within the tuple fits by making the null bitmap 4 bytes shorter. That seems worth a few cycles but isn't going to affect every table. It'll only affect tables that have a null bitmap between 2-5 bytes (mod 8), ie, with 9-40 fields at least one of which is null. Tables with 9 fields are likely to be relatively wide which means saving 4 bytes isn't that much of a gain percentagewise. (Though they might be mostly null....) The other 4 bytes you could save is by packing the whole tuples themselves more closely on the page. That happens when the item pointer is added and pointed to the tuple. To do that heap_form_tuple would have to return data back to the caller about the alignment needed to whomever is going to copy it into the page. AFAICS that could be done in the HeapTuple structure itself rather than in the tuple though which doesn't seem so bad. Tom may be seeing something I'm not though. Incidentally, can't you set the alignment during the compute_data_size() call instead of doing an extra pass through the attributes? Probably doesn't change the cost though. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
