X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org
Received: from localhost (av.hub.org [200.46.204.144])
	by postgresql.org (Postfix) with ESMTP id 678179DCB11
	for <pgsql-performance-postgresql.org@localhost.postgresql.org>;
	Sat,  3 Dec 2005 08:38:48 -0400 (AST)
Received: from postgresql.org ([200.46.204.71])
	by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
	with ESMTP id 82452-07
	for <pgsql-performance-postgresql.org@localhost.postgresql.org>;
	Sat,  3 Dec 2005 08:38:44 -0400 (AST)
X-Greylist: from auto-whitelisted by SQLgrey-
Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54])
	by postgresql.org (Postfix) with ESMTP id 2E1C09DCABE
	for <pgsql-performance@postgresql.org>;
	Sat,  3 Dec 2005 08:38:45 -0400 (AST)
Received: from [192.168.0.4] (unknown [84.12.156.169])
	by smtp.nildram.co.uk (Postfix) with ESMTP
	id A2EDD252E84; Sat,  3 Dec 2005 12:38:46 +0000 (GMT)
Subject: Re: Database restore speed
From: Simon Riggs <simon@2ndquadrant.com>
To: Stephen Frost <sfrost@snowman.net>
Cc: Luke Lonergan <LLonergan@greenplum.com>, David Lang <dlang@invendra.net>,
	Steve Oualline <soualline@stbernard.com>, pgsql-performance@postgresql.org
In-Reply-To: <20051202201847.GE6026@ns.snowman.net>
References: <3E37B936B592014B978C4415F90D662D01C48F01@MI8NYCMAIL06.Mi8.com>
	<20051202201847.GE6026@ns.snowman.net>
Content-Type: text/plain
Date: Sat, 03 Dec 2005 12:38:48 +0000
Message-Id: <1133613528.2906.731.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, score=0 required=5 tests=[none]
X-Spam-Score: 0
X-Spam-Level: 
X-Archive-Number: 200512/96
X-Sequence-Number: 15917

On Fri, 2005-12-02 at 15:18 -0500, Stephen Frost wrote:

> The other thought, of course, is that you could use PITR for your
> backups instead of pgdump...

Yes, it is much faster that way.

Over on -hackers a few optimizations of COPY have been discussed; one of
those is to optimize COPY when it is loading into a table created within
the same transaction as the COPY. This would allow pg_dumps to be
restored much faster, since no WAL need be written in this case.
I hope to work on this fairly soon.

Dumping/restoring data with pg_dump has wider uses than data protecting
backup.

Best Regards, Simon Riggs