On 6/4/18 20:55, Jeff Janes wrote:
> The user docs say about column defaults: "The value is any variable-free
> expression (subqueries and cross-references to other columns in the
> current table are not allowed)"
>
> And also say about pg_get_expr "If the expression might contain Vars,
> specify the OID of the relation they refer to as the second parameter;
> if no Vars are expected, zero is sufficient"
>
> Since defaults can't contain Vars, this patch converts the second
> parameter to zero in places where pg_get_expr is invoked on column
> defaults.
My in-progress generated columns patch removes that assumption (since a
generated column generally refers to another column of the same table).
> Doing this drops the time needed to run `pg_dump -s` on a
> 1600 column table with defaults on all columns by a factor of 40. So
> pg_upgrade users with such tables should see a big win (cc Justin).
That's impressive but also a bit disturbing. Where does this
performance change come from? Can we harness it in different ways?
> I have not tested the pg_upgrade using source versions <8.4, because I
> can't get anything that old to "make check" correctly, so I have nothing
> to test on.
If you have trouble getting older PostgreSQL versions to run, try
building with -O0.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services