On Wed, Jul 10, 2013 at 12:46:26PM -0400, Tom Lane wrote: > Jerry Sievers <gsievers19@xxxxxxxxxxx> writes: > > Kevin Grittner <kgrittn@xxxxxxxxx> writes: > >> Jerry Sievers <gsievers19@xxxxxxxxxxx> wrote: > >>> Planning to pg_upgrade some large (3TB) clusters using hard link > >>> method.� Run time for the upgrade itself takes around 5 minutes. > >>> Unfortunately the post-upgrade analyze of the entire cluster is going > >>> to take a minimum of 1.5 hours running several threads to analyze all > >>> tables.� This was measured in an R&D environment. > > At least for some combinations of source and destination server > versions, it seems like it ought to be possible for pg_upgrade to just > move the old cluster's pg_statistic tables over to the new, as though > they were user data. pg_upgrade takes pains to preserve relation OIDs > and attnums, so the key values should be compatible. Except in > releases where we've added physical columns to pg_statistic or made a > non-backward-compatible redefinition of statistics meanings, it seems > like this should Just Work. In cases where it doesn't work, pg_dump > and reload of that table would not work either (even without the > anyarray problem). Yes, we could certainly do that, but since 9.2 creates an incremental statistics build script, I need someone to say that is too slow before I code up something more complex. -- Bruce Momjian <bruce@xxxxxxxxxx> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
