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

On 06/24/2013 02:21 PM, Tom Lane wrote:
>> Right, but I'm worried about the "surprise!" factor. That is, if we
>> make the first default "free" by using a magic value, then a SET DEFAULT
>> on that column is going to have some very surprising results as suddenly
>> the whole table needs to get written out for the old default.
>
> No, that's why we'd store the magic default separately. That will be
> permanent and unaffected by later SET DEFAULT operations. (This
> requires that every subsequently created tuple store the column
> explicitly so that the magic default doesn't affect it; which is exactly
> why there's a conflict with the currently-proposed patch.)

Yah. So how likely is this to get done sometime in the next 2 releases?
It's only a conflict if someone is going to write the code ...

> Agreed; there are a lot of things we'd have to address if we really
> wanted to claim this is a domain we work well in. (I suspect Salesforce
> will be chipping away at some of those issues, but as I said,
> heap_form_tuple is not in their critical path.)

Well, doing the trailing column truncation as part of a general plan to
make having 600 columns less painful would make more sense than doing it
on its own. For my personal use case(s), I don't really care about the
null bitmap that much; that amount of space simply isn't that
significant compared to the other performance issues involved. I
started evaluating this patch just because I'm one of the few people
with a realistic test case.

Anyway, let's decide if acceptance of this patch hinges on performance
or not. I'll take me a whole evening to set up a good performance test,
so I don't want to do it if it's going to be a moot point.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com