Re: patch submission: truncate trailing nulls from heap rows to reduce the size of the null bitmap - Mailing list pgsql-hackers

<div style="color:#000; background-color:#fff; font-family:tahoma, new york, times, serif;font-size:10pt"><div
style="font-size:10pt; "><span style="font-size: small; ">Thanks for the response.</span><br /></div><div
style="font-family:tahoma, 'new york', times, serif; "><div style="font-family: 'times new roman', 'new york', times,
serif;"><div id="yiv1234046135"><div style="color: rgb(0, 0, 0); background-color: rgb(255, 255, 255); font-family:
tahoma,'new york', times, serif; "><div style="font-size: 10pt; "><font size="2"><br /></font></div><div
style="font-size:10pt; "><font size="2">The use-case I'm targeting is a schema that has multiple tables with ~800
columns,most of which have only the first 50 or so values set. 800 columns would require 800 bits in a bitmap which
equatesto 100 bytes. With 8-byte alignment the row bitmap would take up 104 bytes with the current implementation. If
onlythe first 50 or so columns are actually non-null, then the minimum bitmap size wouldn't need to be more than 8
bytes,which means the proposed change would save 96 bytes. For the data set I have in mind roughly 90% of the rows
wouldfall into the category of needing only 8 bytes for the null bitmap.<br /></font></div><div style="font-size: 10pt;
"><fontsize="2"><br /></font></div><div style="font-size: 10pt; "><font size="2">What kind of test results would prove
thatthis is a net win (or not a net loss) for typical cases? Are you interested in some insert performance tests? Also,
howwould you define a typical case (e.g. what kind of data shape)?</font></div><div style="font-size: 10pt; "><font
size="2"><br/>Thanks.</font></div><div style="font-size: 10pt; "><span style="font-size:13px;">-jamie</span></div><div
style="font-size:10pt; font-family: tahoma, times, serif; "><br /></div><div style="font-size: 10pt; font-family:
tahoma,times, serif; "><div style="font-size: 12pt; font-family: times, serif; "><div dir="ltr"><font face="Arial"
size="2"><hrsize="1" /><b><span style="font-weight:bold;">From:</span></b> Tom Lane <tgl@sss.pgh.pa.us><br
/><b><spanstyle="font-weight:bold;">To:</span></b> Jameison Martin <jameisonb@yahoo.com> <br /><b><span
style="font-weight:bold;">Cc:</span></b>"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org> <br
/><b><spanstyle=" 
font-weight:bold;">Sent:</span></b> Tuesday, April 17, 2012 9:38 AM<br /><b><span
style="font-weight:bold;">Subject:</span></b>Re: [HACKERS] patch submission: truncate trailing nulls from heap rows to
reducethe size of the null bitmap <br /></font></div><br /> Jameison Martin <<a href="mailto:jameisonb@yahoo.com"
rel="nofollow"target="_blank" ymailto="mailto:jameisonb@yahoo.com">jameisonb@yahoo.com</a>> writes:<br />> The
followingpatch truncates trailing null attributes from heap rows to reduce the size of the row bitmap. <br /><br />This
hasbeen discussed before, but it always seemed that the<br />cost-benefit ratio was exceedingly questionable.  You
don'tget any<br />savings whatsoever unless you reduce the size of the null bitmap across<br />a MAXALIGN boundary,
whichmore and more often is 64 bits, so that the<br />frequency with which the optimization wins anything doesn't look
likely<br/>to be that high.  And on the other side of the coin, you're adding<br />cycles to every single
tuple-constructionoperation to make this work.<br />The introduction of bugs doesn't seem improbable either.  (Just
because<br/>tuples in user tables might have unexpected natts values doesn't mean<br />that the code is, or should be,
preparedto tolerate that in system<br />tables or plan-constructed tuples.)<br /><br />So what I'd like to see is some
concretetest results proving that this<br />is a net win, or at least not a net loss, for typical cases.  Just<br
/>assertingthat it might be a win for certain usage patterns doesn't do<br />it for me.<br /><br />            regards,
tomlane<br /><br /><br /></div></div></div></div><br /><br /></div></div></div>