On Sat, Apr 28, 2012 at 6:23 PM, Greg Stark wrote:
On Fri, Apr 27, 2012 at 1:51 AM, Josh Berkus 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

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 15 of 28 | next ›
Discussion Overview
grouppgsql-hackers @
postedApr 17, '12 at 4:23p
activeAug 10, '12 at 12:06a



site design / logo © 2021 Grokbase