pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Denis <socsam@gmail.com>
To: pgsql-performance@postgresql.org
Subject: Re: [HACKERS] pg_dump and thousands of schemas
Date: Tue, 13 Nov 2012 19:12:39 -0800 (PST)
Message-ID: <1352862759173-5731900.post@n5.nabble.com> (raw)
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>

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.




view thread (66+ messages)  latest in thread

Message-ID: <1352862759173-5731900.post@n5.nabble.com>
Permalink:  ../1352862759173-5731900.post@n5.nabble.com/
Also on:    postgresql.org/message-id/1352862759173-5731900.post@n5.nabble.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: socsam@gmail.com
  Subject: Re: [HACKERS] pg_dump and thousands of schemas
  In-Reply-To: <1352862759173-5731900.post@n5.nabble.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox