pg_migrator to /contrib in a later 9.0 beta
in [PgSql]
|
Prev: [HACKERS] pg_migrator to /contrib in a later 9.0 beta
Next: [HACKERS] failed assertion and panic in standby mode
From: Tom Lane on 6 May 2010 10:19 Bruce Momjian <bruce(a)momjian.us> writes: > Jesper Krogh wrote: >> I should have written: >> Why isn't statistics copied over or why doesnt pg_migrator run analyze by >> itself? > Yeah, the statistics are part of the system tables, and system tables > are fully handled by pg_dumpall --schema-only (except for statistics). > There might be changes in the system table statistics format that would > break if pg_migrator tried to migrate the statistics. Right, it's not really practical for pg_migrator to just copy over the statistics without any intelligence. We might at some time choose to teach it which stats could be copied safely, but that hardly seems like something to do in version 1.0 --- and anyway it could not be a 100% solution. > And if pg_migrator ran analyze itself, it would greatly increase its > great migration times! Exactly. It's not a win for pg_migrator to not give you back control of the database until everything has been ANALYZEd. That's a task that can likely be done in background. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Bruce Momjian on 6 May 2010 11:14 Tom Lane wrote: > Bruce Momjian <bruce(a)momjian.us> writes: > > Jesper Krogh wrote: > >> I should have written: > >> Why isn't statistics copied over or why doesnt pg_migrator run analyze by > >> itself? > > > Yeah, the statistics are part of the system tables, and system tables > > are fully handled by pg_dumpall --schema-only (except for statistics). > > There might be changes in the system table statistics format that would > > break if pg_migrator tried to migrate the statistics. > > Right, it's not really practical for pg_migrator to just copy over the > statistics without any intelligence. We might at some time choose to > teach it which stats could be copied safely, but that hardly seems like > something to do in version 1.0 --- and anyway it could not be a 100% > solution. > > > And if pg_migrator ran analyze itself, it would greatly increase its > > great migration times! > > Exactly. It's not a win for pg_migrator to not give you back control of > the database until everything has been ANALYZEd. That's a task that can > likely be done in background. I have to keep those sub-minute migration times for bragging rights. :-) -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Bruce Momjian on 6 May 2010 11:19 Tom Lane wrote: > Bruce Momjian <bruce(a)momjian.us> writes: > > Jesper Krogh wrote: > >> I should have written: > >> Why isn't statistics copied over or why doesnt pg_migrator run analyze by > >> itself? > > > Yeah, the statistics are part of the system tables, and system tables > > are fully handled by pg_dumpall --schema-only (except for statistics). > > There might be changes in the system table statistics format that would > > break if pg_migrator tried to migrate the statistics. > > Right, it's not really practical for pg_migrator to just copy over the > statistics without any intelligence. We might at some time choose to > teach it which stats could be copied safely, but that hardly seems like > something to do in version 1.0 --- and anyway it could not be a 100% > solution. It seems copying over pg_statistic would require preservation of pg_class.oid. Right now we only preserve pg_class.relfilenode. -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Alvaro Herrera on 6 May 2010 11:32 Excerpts from Bruce Momjian's message of jue may 06 11:19:27 -0400 2010: > It seems copying over pg_statistic would require preservation of > pg_class.oid. Right now we only preserve pg_class.relfilenode. That could be fixed easily by creating a throwaway table which included the qualified table name instead of the OID, and reloading it into pg_statistic after the migration. Perhaps this could be done as a regular task in the old database before bringing the server down. -- -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 6 May 2010 11:49
Alvaro Herrera <alvherre(a)alvh.no-ip.org> writes: > Excerpts from Bruce Momjian's message of jue may 06 11:19:27 -0400 2010: >> It seems copying over pg_statistic would require preservation of >> pg_class.oid. Right now we only preserve pg_class.relfilenode. > That could be fixed easily by creating a throwaway table which included the > qualified table name instead of the OID, and reloading it into pg_statistic > after the migration. Yeah. Casting to and from regclass would do the trick too. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |