From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | Denis <socsam(at)gmail(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: [HACKERS] pg_dump and thousands of schemas |
Date: | 2012-11-09 20:47:37 |
Message-ID: | CAMkU=1xZbfCJL1+GrjMBXqDxtBAEvAEpk6-6tUaKM6_wRdiRRg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-performance |
On Thu, Nov 8, 2012 at 1:04 AM, Denis <socsam(at)gmail(dot)com> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2012-11-09 23:06:41 | Re: Further pg_upgrade analysis for many tables |
Previous Message | Simon Riggs | 2012-11-09 20:31:43 | Re: TRUNCATE SERIALIZABLE and frozen COPY |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-11-10 15:32:25 | Re: parallel query evaluation |
Previous Message | Andres Freund | 2012-11-09 17:53:45 | Re: Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries |