Re: ALTER TABLE ADD COLUMN fast default
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, 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:34:55Z
Lists: pgsql-hackers
Hi, On 2018-03-30 00:28:43 +0200, Tomas Vondra wrote: > > 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. I'm also complaining nearby that the "stored default" values should only be loaded on demand. We very regularly build relcache entries that'll never have their default values queried. Even moreso with partitioned tables. Greetings, Andres Freund
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