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 14:24:14 |
Message-ID: | CAPs+M8L2qA1HjbQqrK7B9wGDdFbwrQPbCOjHKWNdwY5eioVkjQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Mon, Jun 10, 2013 at 2:08 PM, Andres Freund <andres(at)2ndquadrant(dot)com>wrote:
> On 2013-06-10 13:28:32 +0000, Gunnlaugur Thor Briem wrote:
> > The three queries taking O(N) time are listed below. AFAICT each of these
>
> Which of those queries take how long in your case?
>
They were as follows:
duration: 27770.917 ms statement: SELECT c.tableoid, c.oid, c.relname, ...
duration: 28133.407 ms statement: SELECT tableoid, oid, typname, ...
duration: 55751.996 ms statement: SELECT classid, objid, refclassid, ...
However, that was running pg_dump remotely over a slow network, and that
may exaggerate durations since it's a bunch of data. So I ran this again
locally on the production server:
duration: 16012.518 ms statement: SELECT c.tableoid, c.oid, c.relname, ...
duration: 16516.708 ms statement: SELECT tableoid, oid, typname, ...
duration: 13400.694 ms statement: SELECT classid, objid, refclassid, ...
Duration decrease is probably *not* significantly due to a warmer cache,
because I had two runs over the slow network and their durations were
similar (actually longer the second time).
Gulli
From | Date | Subject | |
---|---|---|---|
Next 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 |
Previous Message | Gunnlaugur Thor Briem | 2013-06-10 14:11:34 | Re: pg_dump is O(N) in DB table count N even if dumping only one table |