Horton

Re: ALTER TABLE ADD COLUMN fast default

David Rowley <david.rowley@2ndquadrant.com>

View thread View on postgr.es
From: David Rowley <david.rowley@2ndquadrant.com>
To: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
Cc: Andres Freund <andres@anarazel.de>, Thomas Munro <thomas.munro@enterprisedb.com>, Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2018-03-14T00:28:35Z
Lists: pgsql-hackers 
On 14 March 2018 at 11:36, Andrew Dunstan
<andrew.dunstan@2ndquadrant.com> wrote:
> Here are the benchmark results from the v15 patch. Fairly similar to
> previous results. I'm going to run some profiling again to see if I
> can identify any glaring hotspots. I do suspect that the "physical
> tlist" optimization sometimes turns out not to be one. It seems
> perverse to be able to improve a query's performance by dropping a
> column.

Can you explain what "fdnmiss" is that appears in the results?


-- 
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, 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