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>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Petr Jelinek <petr.jelinek@2ndquadrant.com>, Andrew Dunstan <andrew.dunstan@2ndquadrant.com>, Thomas Munro <thomas.munro@enterprisedb.com>, David Rowley <david.rowley@2ndquadrant.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2018-02-20T21:25:14Z
Lists: pgsql-hackers

On 02/20/2018 09:36 PM, Andres Freund wrote:
> Hi,
> 
> On 2018-02-20 21:28:40 +0100, Tomas Vondra wrote:
>> I don't quite understand why would this case need the TPC-H tests, or
>> why would TPC-H give us more than the very focused tests we've already
>> done.
> 
> Because a more complex query shows the cost of changing cache access
> costs better than a trivial query. Simplistic queries will often
> e.g. not show cost of additional branch predictor usage, because the
> branch history is large enough to fit the simple query. But once you go
> to a more complex query, and that's not necessarily the case anymore.
> 
> 
>> The first test was testing a fairly short query where any such
>> additional overhead would be much more obvious, compared to the TPC-H
>> queries that usually do a lot of other expensive stuff.
> 
> Unfortunately such reasoning IME doesn't work well with cpu-bound stuff.
> 

OK, point taken. I'll do the tests and report the results.


regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


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