Re: ALTER TABLE ADD COLUMN fast default
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2017-12-06T15:16:34Z
Lists: pgsql-hackers
Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes: > Attached is a patch for $subject. It's based on Serge Reilau's patch of > about a year ago, taking into account comments made at the time. with > bitrot removed and other enhancements such as documentation. > Essentially it stores a value in pg_attribute that is used when the > stored tuple is missing the attribute. This works unless the default > expression is volatile, in which case a table rewrite is forced as > happens now. I'm quite disturbed both by the sheer invasiveness of this patch (eg, changing the API of heap_attisnull()) and by the amount of logic it adds to fundamental tuple-deconstruction code paths. I think we'll need to ask some hard questions about whether the feature gained is worth the distributed performance loss that will ensue. regards, tom lane
Commits
-
Clean up treatment of missing default and CHECK-constraint records.
- 091e22b2e673 14.0 landed
-
Fast ALTER TABLE ADD COLUMN with a non-NULL default
- 16828d5c0273 11.0 landed
-
Fix application of identity values in some cases
- 533c5d8bddf0 11.0 cited