Message-ID: <443A7FC7.2000001@krogh.cc>
Date: Mon, 10 Apr 2006 17:54:47 +0200
From: Jesper Krogh <jesper@krogh.cc>
User-Agent: Mail/News 1.5 (X11/20060309)
MIME-Version: 1.0
To: Rajesh Kumar Mallah <mallah.rajesh@gmail.com>
CC: pgsql-performance@postgresql.org
Subject: Re: Restore performance?
References: <e1d31l$2nt$1@sea.gmane.org>
	<a97c77030604100839p2c4b15c9q88f1258287a0e6d0@mail.gmail.com>
In-Reply-To: <a97c77030604100839p2c4b15c9q88f1258287a0e6d0@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Rajesh Kumar Mallah wrote:
>> I'd run pg_dump | gzip > sqldump.gz  on the old system. That took about
>> 30 hours and gave me an 90GB zipped file. Running
>> cat sqldump.gz | gunzip | psql
>> into the 8.1 database seems to take about the same time. Are there
>> any tricks I can use to speed this dump+restore process up?
> 
> 
> was the last restore successfull ?
> if so why do you want to repeat ?

"about the same time" == Estimated guess from restoring a few tables
I was running a testrun, without disabling updates to the production
database, the real run is scheduled for easter where there hopefully is
no users on the system. So I need to repeat, I'm just trying to get a
feelingabout how long time I need to allocate for the operation.

> 1. run new version of postgres in a different port and pipe pg_dump to psql
> this may save the CPU time of compression , there is no need for a temporary
> dump file.
> 
> pg_dump | /path/to/psql813  -p 54XX newdb

I'll do that. It is a completely different machine anyway.

> 2. use new version of pg_dump to dump the old database as new version
>     is supposed to be wiser.

Check.

> 3. make sure you are trapping the restore errors properly
> psql newdb 2>&1 | cat | tee err works for me.

Thats noted.

-- 
Jesper Krogh, jesper@krogh.cc