Re: ALTER TABLE ADD COLUMN fast default - Mailing list pgsql-hackers

From Tom Lane
Subject Re: ALTER TABLE ADD COLUMN fast default
Date
Msg-id 19612.1519157666@sss.pgh.pa.us
Whole thread Raw
In response to Re: ALTER TABLE ADD COLUMN fast default  (Andres Freund <andres@anarazel.de>)
Responses Re: ALTER TABLE ADD COLUMN fast default
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2018-02-20 20:57:36 +0100, Tomas Vondra wrote:
>> The question is how should the schema for TPC-H look like. Because if
>> you just do the usual test without any ALTER TABLE ADD COLUMN, then you
>> really won't get any difference at all. The fast default stuff will be
>> completely "inactive".

> I think just verifying that there's no meaningful effect with/without
> the patch is good enough. As soon as there's actual new columns that
> take advantage of the new functionality I think some degradation is fair
> game, you got some benefit for it.

Yeah, I think what we want to know is how much penalty people are paying
for the feature to exist even though they aren't using it.  That seems
to break down into two cases:

(1) use of a table that's never had any added columns;

(2) use of a table that has had columns added, but they just default
to null the same as before.  Is there more relcache setup time anyway?
Is deforming slower even if there are no fast defaults?

Case (1) could be answered by a straight TPC-H test with/without patch.
Case (2) seems a bit harder, since presumably you want to measure accesses
to tuples that are "short" compared to the current table tupdesc, but for
which the extra columns are still default-null.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: ALTER TABLE ADD COLUMN fast default
Next
From: Tomas Vondra
Date:
Subject: Re: ALTER TABLE ADD COLUMN fast default