For sure I'll work on that now. One thing I noticed looking through the pg_dump code based on the messages and the code one thing I noticed it seems to be grabbing the full dependency graph for the whole db rather then limiting it by the schema (not sure if limiting this would be possible)
This query returns 9843923 rows from the DB. So processing this seems like it'll take quite a while.
I'll get a -pg build of pg_dump going here on a dev box so I can get you a profile.
On Fri, Mar 30, 2012 at 10:18 AM, Tom Lane
<tgl@sss.pgh.pa.us> wrote:
Mike Roest <
mike.roest@replicon.com> writes:
> This dump is currently taking around 8 minutes. While dumping the pg_dump
> process is using 100% of one core in the server (24 core machine). Doing a
> -v pg_dump I found that the following stages are taking the majority of the
> time
> reading user_defined tables (2 minutes and 20 seconds)
> reading dependency data (5 minutes and 30 seconds)
It doesn't surprise me a lot that pg_dump might have some issues with
large numbers of objects, but guessing which inefficiencies are hurting
you is difficult without more info.
regards, tom lane