Re: [HACKERS] pg_dump and thousands of schemas
Jeff Janes <jeff.janes@gmail.com>
From: Jeff Janes <jeff.janes@gmail.com>
To: Denis <socsam@gmail.com>
Cc: pgsql-performance@postgresql.org
Date: 2012-11-14T03:40:57Z
Lists: pgsql-hackers, pgsql-performance
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Teach AbortOutOfAnyTransaction to clean up partially-started transactions.
- 2755abf386e6 9.2.0 cited
On Tue, Nov 13, 2012 at 7:12 PM, Denis <socsam@gmail.com> 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