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

From Amit Kapila
Subject Re: patch submission: truncate trailing nulls from heap rows to reduce the size of the null bitmap [Review]
Date
Msg-id 00bd01ce7196$e4447d90$accd78b0$@kapila@huawei.com
Whole thread Raw
In response to Re: patch submission: truncate trailing nulls from heap rows to reduce the size of the null bitmap [Review]  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: patch submission: truncate trailing nulls from heap rows to reduce the size of the null bitmap [Review]
List pgsql-hackers
On Monday, June 24, 2013 8:20 PM Tom Lane wrote:
> Amit Kapila <amit.kapila@huawei.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.




pgsql-hackers by date:

Previous
From: Szymon Guz
Date:
Subject: Re: [PATCH] Fix conversion for Decimal arguments in plpython functions
Next
From: Dean Rasheed
Date:
Subject: Re: Naming of ORDINALITY column