Re: patch submission: truncate trailing nulls from heap rows to reduce the size of the null bitmap
Simon Riggs <simon@2ndquadrant.com>
From: Simon Riggs <simon@2ndQuadrant.com>
To: Josh Berkus <josh@agliodbs.com>
Cc: pgsql-hackers@postgresql.org
Date: 2012-04-27T10:06:02Z
Lists: pgsql-hackers
On Fri, Apr 27, 2012 at 1:51 AM, Josh Berkus <josh@agliodbs.com> wrote: > Now, the other issue I'd be worried about for this optimization is what > happens when the nulls become non-trailing? For example, this pattern: > > 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. > > If your application had a lot of that kind of update pattern, I'd be > concerned that this would be a deoptimzation. Currently, we have a long row before and a long row after. Jamie's proposals would give us a short row before and a long row after. Since we don't ever update in place, we're much more likely to fit on the same page with this optimisation than without it. I guess we can check that with a performance test. (Perhaps a more obvious optimisation would be to use a compressed NULL bitmap. That would respond better in a wider range of use cases than just truncation of trailing zeroes.) -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services