Re: pg_dump is O(N) in DB table count N even if dumping only one table - Mailing list pgsql-bugs

From Gunnlaugur Thor Briem
Subject Re: pg_dump is O(N) in DB table count N even if dumping only one table
Date
Msg-id CAPs+M8JbtOvXSh3nzktcf1APGPpf=VgYnX_sgeQnUDCyyyj7pw@mail.gmail.com
Whole thread Raw
In response to Re: pg_dump is O(N) in DB table count N even if dumping only one table  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
OK, that was what I thought at first, but then I read this note in `man
pg_dump`:

    When -t is specified, pg_dump makes no attempt to dump any other
database objects that the selected table(s) might depend upon.

so I supposed that that dependency information was *not* required. So I
posted the bug.

Is that note then outdated/incorrect? Or am I mistaken in finding it at
odds with your explanation?

Regards,

Gulli



On Mon, Jun 10, 2013 at 2:04 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Gunnlaugur Thor Briem <gunnlaugur@gmail.com> writes:
> > pg_dump takes O(N) time dumping just one table (or a few) explicitly
> > specified with a -t parameter. It thus becomes painfully slow on a
> database
> > with very many tables.
>
> This is not a bug.  It needs information about all the tables anyway
> to deal with dependencies (possible inheritance and similar situations).
>
> Having said that, it does look like getTables is pulling back a lot of
> info that we don't need *yet*, and would never need if we conclude we
> don't need to dump the table.  Possibly some of this work could usefully
> be postponed to, say, getTableAttrs.  OTOH, if that makes the normal
> dump-everything case noticeably slower, it's unlikely such a patch would
> get accepted.
>
>                         regards, tom lane
>

pgsql-bugs by date:

Previous
From: Andres Freund
Date:
Subject: Re: pg_dump is O(N) in DB table count N even if dumping only one table
Next
From: Gunnlaugur Thor Briem
Date:
Subject: Re: pg_dump is O(N) in DB table count N even if dumping only one table