Re: pg_dump is O(N) in DB table count N even if dumping only one table

From: Gunnlaugur Thor Briem <gunnlaugur(at)gmail(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: pg_dump is O(N) in DB table count N even if dumping only one table
Date: 2013-06-10 15:29:51
Message-ID: CAPs+M8+pVfShRq3QsVhGVkWJBEcVezD5CYPKCCmCEcNUv1pMcQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Mon, Jun 10, 2013 at 2:38 PM, Andres Freund <andres(at)2ndquadrant(dot)com>wrote:

> Hm. 13s for pg_depend locally vs 55s remotely. You need to have a
> tremendous amount of dependencies.
> Could you do a count(*) of pg_depend, pg_type and pg_class?
>

Yep, there's rather a lot:

select count(*) from pg_depend;
7692365

select count(*) from pg_type;
1302222

select count(*) from pg_class;
1788727

It's a very-broad-scope heterogeneous data warehouse, hence the unusual
table count. PostgreSQL has displayed tremendous grace under this fire, the
only trouble we've encountered is small niggles like tab completion in psql
and pg_dump performance (and the latter was helped a lot by the pg_dump
perf improvements in 9.1.4 and 9.2, for larger dumps). All the same we will
undoubtedly end up spreading all this to more instances/clusters eventually
(the dependency structure allows for that).

Gulli

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2013-06-10 18:45:26 Re: bug in Prepared statement with DELETE RETURNING and rule on view
Previous Message Andres Freund 2013-06-10 14:38:41 Re: pg_dump is O(N) in DB table count N even if dumping only one table