Re: ALTER TABLE ADD COLUMN fast default
Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
From: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2017-12-06T15:47:12Z
Lists: pgsql-hackers
On 12/06/2017 10:16 AM, Tom Lane wrote: > 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. > > Thanks for prompt comments. I'm sure we can reduce the footprint some. w.r.t. heap_attisnull, only a handful of call sites actually need the new functionality, 8 or possibly 10 (I need to check more on those in relcache.c). So we could instead of changing the function provide a new one to be used at those sites. I'll work on that. and submit a new patch fairly shortly. cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
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