Date: Tue, 13 Nov 2012 19:12:39 -0800 (PST)
From: Denis <socsam@gmail.com>
To: pgsql-performance@postgresql.org
Message-ID: <1352862759173-5731900.post@n5.nabble.com>
In-Reply-To: 
 <CAMkU=1xZbfCJL1+GrjMBXqDxtBAEvAEpk6-6tUaKM6_wRdiRRg@mail.gmail.com>
References: 
 <CAMkU=1xAUY_aCiWeVL1J5Xrub4vMObWG9UnOQrTR==6z4w1dUw@mail.gmail.com>
	<CA+TgmobHDYs2RoL0P+Fx0-W-f00ziy8M6pE7tSCuDAt8OTyRNg@mail.gmail.com>
	<1352211374706-5730864.post@n5.nabble.com>
	<13005.1352214454@sss.pgh.pa.us>
	<1352216421913-5730877.post@n5.nabble.com>
	<16061.1352224264@sss.pgh.pa.us>
	<1352284972611-5730998.post@n5.nabble.com>
	<8407.1352300557@sss.pgh.pa.us>
	<1352365474583-5731188.post@n5.nabble.com>
	<CAMkU=1xZbfCJL1+GrjMBXqDxtBAEvAEpk6-6tUaKM6_wRdiRRg@mail.gmail.com>
Subject: Re: [HACKERS] pg_dump and thousands of schemas
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Jeff Janes wrote
> On Thu, Nov 8, 2012 at 1:04 AM, Denis &lt;

> socsam@

> &gt; wrote:
>>
>> Still I can't undesrtand why pg_dump has to know about all the tables?
> 
> Strictly speaking it probably doesn't need to.  But it is primarily
> designed for dumping entire databases, and the efficient way to do
> that is to read it all into memory in a few queries and then sort out
> the dependencies, rather than tracking down every dependency
> individually with one or more trips back to the database.  (Although
> it still does make plenty of trips back to the database per
> table/sequence, for acls, defaults, attributes.
> 
> If you were to rewrite pg_dump from the ground up to achieve your
> specific needs (dumping one schema, with no dependencies between to
> other schemata) you could probably make it much more efficient.  But
> then it wouldn't be pg_dump, it would be something else.
> 
> Cheers,
> 
> Jeff
> 
> 
> -- 
> Sent via pgsql-performance mailing list (

> pgsql-performance@

> )
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance

Please don't think that I'm trying to nitpick here, but pg_dump has options
for dumping separate tables and that's not really consistent with the idea
that "pg_dump is primarily  designed for dumping entire databases".


--
View this message in context: http://postgresql.1045698.n5.nabble.com/pg-dump-and-thousands-of-schemas-tp5709766p5731900.html
Sent from the PostgreSQL - performance mailing list archive at Nabble.com.