Josh Berkus <josh@agliodbs.com> writes:
> On 06/24/2013 01:50 PM, Tom Lane wrote:
>> The point of what I was suggesting isn't to conserve storage, but to
>> reduce downtime during a schema change. Remember that a rewriting ALTER
>> TABLE locks everyone out of that table for a long time.
> 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.)
> ... Also for the reason Tom pointed out, the
> optimization would only work on with NOT NULL columns ... leading to
> another potential unexpected surprise when the column is marked NULLable.
Huh? We already have the case of null default handled.
> Well, actually, hundreds of columns is reasonably common for a certain
> user set (ERP, CRM, etc.). If we could handle that use case very
> efficiently, then it would win us some users, since other RDMBSes don't.
> However, there are multiple issues with having hundreds of columns, of
> which storage optimization is only one ... and probably the smallest one
> at that.
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.)
regards, tom lane