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
