On Fri, Apr 27, 2012 at 1:51 AM, Josh Berkus <j...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
