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: Andres Freund <andres@anarazel.de>,
David Rowley <david.rowley@2ndquadrant.com>, Thomas Munro <thomas.munro@enterprisedb.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2018-03-29T01:27:55Z
Lists: pgsql-hackers
On Thu, Mar 29, 2018 at 10:19 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes: >> On Wed, Mar 28, 2018 at 5:30 PM, Andres Freund <andres@anarazel.de> wrote: >>> + /* >>> + * Missing value for added columns. This is a one element array which lets >>> + * us store a value of the attribute type here. >>> + */ >>> + anyarray attmissingval BKI_DEFAULT(_null_); >>> #endif >>> } FormData_pg_attribute; >>> >>> Still think this is a bad location, and it'll reduce cache hit ratio for >>> catalog lookups. > >> As I think I mentioned before, this was discussed previously and as I >> understood it this was the consensus location for it. > > I don't have a problem with putting that in pg_attribute (and I certainly > agree with not putting it in pg_attrdef). But "anyarray" seems like a > damn strange, and bulky, choice. Why not just make it a bytea holding the > bits for the value, nothing more? > That's what we started with and Andres suggested we change it. One virtue of the array is that is displays nicely when examining pg_attribute. But changing it back would be easy enough. 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