Re: ALTER TABLE ADD COLUMN fast default
Tomas Vondra <tomas.vondra@2ndquadrant.com>
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: Andres Freund <andres@anarazel.de>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>,
David Rowley <david.rowley@2ndquadrant.com>,
Thomas Munro <thomas.munro@enterprisedb.com>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2018-03-29T22:28:43Z
Lists: pgsql-hackers
On 03/29/2018 11:31 PM, Andres Freund wrote: > Hi, > > On 2018-03-29 17:27:47 -0400, Tom Lane wrote: >> Andres Freund <andres@anarazel.de> writes: >>> There's plenty databases with pg_attribute being many gigabytes large, >>> and this is going to make that even worse. >> >> Only if you imagine that a sizable fraction of the columns have fast >> default values, which seems somewhat unlikely. > > Why is that unlikely? In the field it's definitely not uncommon to > define default values for just about every column. And in a lot of cases > that'll mean we'll end up with pg_attribute containing default values > for most columns but the ones defined at table creation. A lot of > frameworks make it a habit to add columns near exclusively in > incremental steps. You'd only get rid of them if you force an operation > that does a full table rewrite, which often enough is impractical. > I don't quite see how moving that gets solved by moving the info into a different catalog? We would need to fetch it whenever attribute meta-data from pg_attribute are loaded. cheers -- Tomas Vondra http://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