Re: Re: patch submission: truncate trailing nulls from heap rows to reduce the size of the null bitmap

On Sat, Apr 28, 2012 at 6:23 PM, Greg Stark <stark(at)mit(dot)edu> wrote:
> On Fri, Apr 27, 2012 at 1:51 AM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>> 1. Out of 700 columns, columns 301+ are all Null, so we map them away.
>> 2. User updates column 688 to non-null
>> 3. Suddenly we have a MUCH larger row which will no longer fit on the page.
>
> Note that this is only actually 48 bytes more in the null bitmap in
> this scenario. That's part of Tom's point that the null bitmap is so
> dense that you have to be talking about some pretty huge number of
> columns before the size savings are noticeable. Saving 48 bytes is
> nothing to sneeze at but it's hardly an impractical update to handle.

More to the point, if the old row were 48 bytes larger, that would not
increase the chance of the new row fitting on the page. You've got to
store the old and new row no matter what: if the old one can be made
smaller than otherwise, that's a win regardless of whether the new one
is also smaller or not.

The other point I feel we're overlooking here is... according to
Jamie, the patch actually made things FASTER in every case he thought
to test, and those cases don't appear to be anything particularly
favorable to the patch, so that's probably a good sign. I'd like to
see the exact numbers from each test run, and a complete reproducible
test case, but at present all signs seem to point to this change being
a savings in both time and space. Let's not go looking for reasons to
reject the approach just because we didn't expect it to work as well
as it does.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company