Re: ALTER TABLE ADD COLUMN fast default
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Petr Jelinek <petr.jelinek@2ndquadrant.com>,Tomas Vondra
<tomas.vondra@2ndquadrant.com>
Cc: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>,Thomas Munro
<thomas.munro@enterprisedb.com>,David Rowley
<david.rowley@2ndquadrant.com>,Tom Lane
<tgl@sss.pgh.pa.us>,PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2018-02-20T17:43:45Z
Lists: pgsql-hackers
On February 20, 2018 5:03:58 AM PST, Petr Jelinek <petr.jelinek@2ndquadrant.com> wrote: >On 20/02/18 07:42, Andres Freund wrote: >> Hi, >> >> On 2018-02-17 00:23:40 +0100, Tomas Vondra wrote: >>> Anyway, I consider the performance to be OK. But perhaps Andres >could >>> comment on this too, as he requested the benchmarks. >> >> My performance concerns were less about CREATE TABLE related things >than >> about analytics workloads or such, where deforming is the primary >> bottleneck. I think it should be ok, but doing a before/after tpc-h >of >> scale 5-10 or so wouldn't be a bad thing to verify. >> > >The test Tomas is doing is analytical query, it's running sum on the >new >fast default column. > >He uses create and create-alter names as comparison between when the >table was created with the columns and when the columns were added >using >fast default. It's still a fairly simplistic test case. Running some queries with reasonably well known characteristics seems like a good idea regardless. It's not like a scale 5 run takes that long. Andres -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
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