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: Alvaro Herrera on 6 May 2010 00:41 Excerpts from Jesper Krogh's message of jue may 06 00:32:09 -0400 2010: > Q: I read you pdf, why isn't statistics copied over? It seems to be the last > part missing from doing an upgrade in a few minutes. Seems fraught with peril, and a bit pointless. What's so bad about having to run ANALYZE afterwards? -- -- 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: Jesper Krogh on 6 May 2010 00:53 On 2010-05-06 06:41, Alvaro Herrera wrote: > Excerpts from Jesper Krogh's message of jue may 06 00:32:09 -0400 2010: > > >> Q: I read you pdf, why isn't statistics copied over? It seems to be the last >> part missing from doing an upgrade in a few minutes. >> > Seems fraught with peril, and a bit pointless. What's so bad about having to > run ANALYZE afterwards? > There is nothing directly "bad" about it.. but: It's just "an extra step, that might be overseen and is absolutely required". I should have written: Why isn't statistics copied over or why doesnt pg_migrator run analyze by itself? The database (of a reasonable size) is useless until statistics is available. I guess it is because pg_dump/restore doesn't do it either. Jesper -- Jesper -- 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: Dimitri Fontaine on 6 May 2010 06:03 Jesper Krogh <jesper(a)krogh.cc> writes: > I did go the painful way (dump+restore) at that point in time. > It was an 8.1 - 8.3 migration. Since then data has grown and the dump > restore is even less favorable on the 8.3 -> 9.0 migration. > > So in general the pg_migrator way seems to be the only way to aviod > the slony way which is orders of magnitude more complicated. Right in the middle there's the Londiste way. It works like Slony but the setup is much easier. Regards, -- Dimitri Fontaine PostgreSQL DBA, Architecte -- 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 09:04 Jesper Krogh wrote: > On 2010-05-06 06:41, Alvaro Herrera wrote: > > Excerpts from Jesper Krogh's message of jue may 06 00:32:09 -0400 2010: > > > > > >> Q: I read you pdf, why isn't statistics copied over? It seems to be the last > >> part missing from doing an upgrade in a few minutes. > >> > > Seems fraught with peril, and a bit pointless. What's so bad about having to > > run ANALYZE afterwards? > > > > There is nothing directly "bad" about it.. but: > > It's just "an extra step, that might be overseen and is absolutely > required". > > I should have written: > Why isn't statistics copied over or why doesnt pg_migrator run analyze by > itself? > > The database (of a reasonable size) is useless until statistics is > available. > > I guess it is because pg_dump/restore doesn't do it either. 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 now pg_migrator is immune from any system table changes, and I would like to keep it that way. And if pg_migrator ran analyze itself, it would greatly increase its great migration times! -- 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 09:06
Bruce Momjian wrote: > > The database (of a reasonable size) is useless until statistics is > > available. > > > > I guess it is because pg_dump/restore doesn't do it either. > > 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 now > pg_migrator is immune from any system table changes, and I would like to > keep it that way. > > And if pg_migrator ran analyze itself, it would greatly increase its > great migration times! Forgot the :-). -- 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 |