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
