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
-
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