On Tue, Nov 13, 2012 at 7:12 PM, Denis <socsam@xxxxxxxxx> wrote: > Jeff Janes wrote >> On Thu, Nov 8, 2012 at 1:04 AM, Denis < > >> socsam@ > >> > 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. >> > > 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". I think it is compatible. From my reading of pg_dump, those other options seem to have been bolted on as an afterthought, not as part of its primary design. Cheers, Jeff -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
