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

FYI I submitted a slightly modified patch since Amit's measurements that is slightly faster.

On Jun 25, 2013, at 1:26 PM, Amit Kapila <amit(dot)kapila(at)huawei(dot)com> wrote:

> On Monday, June 24, 2013 8:20 PM Tom Lane wrote:
>> Amit Kapila <amit(dot)kapila(at)huawei(dot)com> writes:
>>> I will summarize the results, and if most of us feel that they are
>> not good
>>> enough, then we can return this patch.
>>
>> Aside from the question of whether there's really any generally-useful
>> performance improvement from this patch, it strikes me that this change
>> forecloses other games that we might want to play with interpretation
>> of
>> the value of a tuple's natts.
>>
>> In particular, when I was visiting Salesforce last week, the point came
>> up that they'd really like ALTER TABLE ADD COLUMN to be "free" even
>> when
>> the column had a non-null DEFAULT. It's not too difficult to imagine
>> how we might support that, at least when the default expression is a
>> constant: decree that if the requested attribute number is beyond
>> natts,
>> look aside at the tuple descriptor to see if the column is marked as
>> having a magic default value, and if so, substitute that rather than
>> just returning NULL. (This has to be a "magic" value separate from
>> the current default, else a subsequent DROP or SET DEFAULT would do
>> the wrong thing.)
>>
>> However, this idea conflicts with an optimization that supposes it can
>> reduce natts to suppress null columns: if the column was actually
>> stored
>> as null, you'd lose that information, and would incorrectly return the
>> magic default on subsequent reads.
>>
>> I think it might be possible to make both ideas play together, by
>> not reducing natts further than the last column with a magic default.
>> However, that means extra complexity in heap_form_tuple, which would
>> invalidate the performance measurements done in support of this patch.
>
> It can have slight impact on normal scenario's, but I am not sure how much
> because
> the change will be very less(may be one extra if check and one assignment)
>
> For this Patch's scenario, I think the major benefit for Performance is in
> heap_fill_tuple() where the
> For loop is reduced. However added some logic in heap_form_tuple can
> reduce the performance improvement,
> but there can still be space saving benefit.
>
> With Regards,
> Amit Kapila.
>