Skip site navigation (1) Skip section navigation (2)

Re: pg_dump incredibly slow dumping a single schema from a large db

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Mike Roest <mike(dot)roest(at)replicon(dot)com>
Cc: pgsql-general(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_dump incredibly slow dumping a single schema from a large db
Date: 2012-03-31 19:56:41
Message-ID: 25863.1333223801@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-hackers
I wrote:
> So this is dumb; we should manage the "is the object already processed"
> component of that with an O(1) check, like a bool array or some such,
> rather than an O(N) search loop.

> As for the getTables slowdown, the only part of that I can see that
> looks to be both significant and entirely contained in getTables()
> itself is the nested loop near the end that's trying to copy
> the dumpable flags for owned sequences from their owning tables.
> Do you have a whole lot of owned sequences?  Maybe we could postpone
> that work until we have the fast table lookup array constructed,
> which should reduce this from O(M*N) to O(M*logN).

I've committed fixes for both these issues.  If you are in a position to
test with 9.1 branch tip from git, it'd be nice to have confirmation
that these patches actually cure your problem.  For both of them, the
issue seems to only show up in a subset of cases, which may explain why
we'd not identified the problem before.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Mike RoestDate: 2012-03-31 20:34:26
Subject: Re: pg_dump incredibly slow dumping a single schema from a large db
Previous:From: Tom LaneDate: 2012-03-31 17:17:12
Subject: Re: [COMMITTERS] pgsql: Add PGDLLIMPORT to ScanKeywords and NumScanKeywords.

pgsql-general by date

Next:From: Mike RoestDate: 2012-03-31 20:34:26
Subject: Re: pg_dump incredibly slow dumping a single schema from a large db
Previous:From: AndreasDate: 2012-03-31 19:56:39
Subject: Re: Problems with Binary Replication

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group