Thanks,
in fact I also expected a couple of hours and I was surprised by this
result.
I will have a look to the hardware (unfortunately not before next week now).
Thanks again.
Rasper, Franz wrote:
Hi,
Normally it should be done in between 1 and 4 hours.
Fastest version is maybe
pg_dump ... | psql ...
27 hours is in my opinion a little bit to much.
What is your hardware ?
Greetings,
-Franz
-----Ursprüngliche Nachricht-----
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Pascal Cohen
Gesendet: Freitag, 10. Oktober 2008 17:17
An: pgsql-general@postgresql.org
Betreff: [Spam] [GENERAL] Improve dump and restore time
Hello,
I am studying how to migrate our Production Database which is running under PG
8.2 and we would like to move to PG 8.3 I have read that the only safe solution
is to perform a dump and restore.
Our DB is around 6GB large.
I wanted to have an expectation of the migration duration and performed it on a
less powerful machine than the one we have in Production.
Unfortunately it took very very long time (around 27 hours!).
Are there best practices to reduce the migration time ?
Some kind of questions I try to solve:
- Is it better to use a compressed dump or not ?
- Should I use a kind of trick like reading dump file from network while
restoring on the machine to reduce concurrent I/O and so on
Any advice is welcome.
Thanks!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make
changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
