From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Gunnlaugur Thor Briem <gunnlaugur(at)gmail(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:04:25 |
Message-ID: | 21114.1370873065@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Gunnlaugur Thor Briem <gunnlaugur(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2013-06-10 14:08:43 | 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 13:28:32 | pg_dump is O(N) in DB table count N even if dumping only one table |