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

  1. Clean up treatment of missing default and CHECK-constraint records.

  2. Fast ALTER TABLE ADD COLUMN with a non-NULL default

  3. Fix application of identity values in some cases