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.kap...@huawei.com> wrote: > On Monday, June 24, 2013 8:20 PM Tom Lane wrote: >> Amit Kapila <amit.kap...@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. > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
