Re: Incredibly slow restore times after 9.0>9.2 upgrade
От | Jerry Sievers |
---|---|
Тема | Re: Incredibly slow restore times after 9.0>9.2 upgrade |
Дата | |
Msg-id | 86k33hwl3w.fsf@jerry.enova.com обсуждение исходный текст |
Ответ на | Re: Incredibly slow restore times after 9.0>9.2 upgrade (jmcdonagh <Joseph.E.McDonagh@gmail.com>) |
Ответы |
Re: Incredibly slow restore times after 9.0>9.2 upgrade
|
Список | pgsql-performance |
jmcdonagh <Joseph.E.McDonagh@gmail.com> writes: > I just had a thought- I know some of these tables are in need of a vacuuming. > Could it be that the dump is dumping a bunch of garbage that the restore has > to sift through on the restore? I don't know enough details to know if this > is a dumb thought or not. No. However it's true that the dump will take a bit longer having to scan a bloated table rather than a tight one. Dump will only output the live rows. psql or pg_restore whatever you're using on the target side will not have to step over any junk. HTH > > The restore to RDS took roughly the same amount of time. My next move is to > try on a fast instance store, and also do a postgres 9 restore of a pure SQL > dump, but that won't really be a great test since I use custom format. I'm > assuming here that I can't take the custom dump from 9.2 and apply it to > 9.0, or can I? > > > > -- > View this message in context: http://postgresql.1045698.n5.nabble.com/Incredibly-slow-restore-times-after-9-0-9-2-upgrade-tp5824701p5825052.html > Sent from the PostgreSQL - performance mailing list archive at Nabble.com. -- Jerry Sievers Postgres DBA/Development Consulting e: postgres.consulting@comcast.net p: 312.241.7800
В списке pgsql-performance по дате отправления: