Received: from localhost (unknown [200.46.204.183])
	by postgresql.org (Postfix) with ESMTP id 474966501A6
	for <pgsql-general-postgresql.org@postgresql.org>;
	Fri, 18 Jul 2008 21:27:34 -0300 (ADT)
Received: from postgresql.org ([200.46.204.86])
	by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024)
	with ESMTP id 78774-04 for
	<pgsql-general-postgresql.org@postgresql.org>;
	Fri, 18 Jul 2008 21:27:16 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from zoraida.natserv.net (p65-147.acedsl.com [66.114.65.147])
	by postgresql.org (Postfix) with ESMTP id 3541765018A
	for <pgsql-general@postgresql.org>;
	Fri, 18 Jul 2008 21:25:52 -0300 (ADT)
Received: from [192.168.1.20] (zoraida.natserv.net [66.114.65.147])
	by zoraida.natserv.net (Postfix) with ESMTP id A6FC41703C;
	Fri, 18 Jul 2008 20:25:50 -0400 (EDT)
Message-ID: <4881348E.3050002@stringsutils.com>
Date: Fri, 18 Jul 2008 20:25:50 -0400
From: Francisco Reyes <lists@stringsutils.com>
User-Agent: Thunderbird 2.0.0.14 (X11/20080421)
MIME-Version: 1.0
To: Simon Riggs <simon@2ndquadrant.com>
CC: John Smith <sodgodofall@gmail.com>, pgsql-general@postgresql.org
Subject: Re: Backup/Restore of single table in multi TB database
References: <b88f0d670805071302h469141e0ke29413edddb444e0@mail.gmail.com>
	<1210195724.4268.231.camel@ebony.site>
In-Reply-To: <1210195724.4268.231.camel@ebony.site>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=0.236 tagged_above=0 required=5 tests=AWL=0.236
X-Spam-Level: 
X-Archive-Number: 200807/709
X-Sequence-Number: 135288

Simon Riggs wrote:
> Have a look at pg_snapclone. It's specifically designed to significantly
> improve dump times for very large objects.
>
> http://pgfoundry.org/projects/snapclone/
>   
Also, in case the original poster is not aware, by default pg_dump 
allows to backup single tables.
Just add -t <table name>.



Does pg_snapclone works mostly on large rows or will it also be faster 
than pg_dump for narrow tables?