From: | Eric Lam <elam(at)lisasoft(dot)com> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Slow restoration question |
Date: | 2006-04-26 07:44:41 |
Message-ID: | 444F24E9.2010907@lisasoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Hello list,
what is the quickest way of dumping a DB and restoring it? I have done a
"pg_dump -D database | split --line-bytes 1546m part"
Restoration as
"cat part* | psql database 2> errors 1>/dev/null"
all dumpfiles total about 17Gb. It has been running for 50ish hrs and up
to about the fourth file (5-6 ish Gb) and this is on a raid 5 server.
A while back I did something similar for a table with where I put all
the insert statements in one begin/end/commit block, this slowed down
the restoration process. Will the same problem [slow restoration] occur
if there is no BEGIN and END block? I assume the reason for slow inserts
in this instance is that it allows for rollback, if this is the case
can I turn this off?
Thanks in advance
Eric Lam
From | Date | Subject | |
---|---|---|---|
Next Message | Ron Peacetree | 2006-04-26 12:40:37 | Re: Large (8M) cache vs. dual-core CPUs |
Previous Message | mark | 2006-04-26 06:48:53 | Re: Large (8M) cache vs. dual-core CPUs |