| From: | "Nikita The Spider The Spider" <nikitathespider(at)gmail(dot)com> |
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: 5 minutes to pg_dump nothing |
| Date: | 2007-09-24 23:28:43 |
| Message-ID: | 35e76ac10709241628k40589782sd7062e6610b47df7@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On 9/23/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I wrote:
> > "Nikita The Spider The Spider" <nikitathespider(at)gmail(dot)com> writes:
> >> Thanks for your help! Given that this problem seems to be triggered by
> >> a sort of edge case and the fix is non-trivial, I guess I should not
> >> expect a new version of pg_dump soon?
>
> > We might look into fixing it for 8.3, but I doubt we'd risk back-patching
> > such a change to older branches.
>
> Actually, it doesn't look that hard --- want to try the attached patch?
> I couldn't measure any speed difference at all on the standard PG
> regression-test database, but there are not huge numbers of objects
> in that.
Tom,
Your patch decreases the runtime of pg_dump by an order of magnitude
for me which means I don't have to roll my own table dumper. Thanks
very much for the swift turnaround and for a great database.
--
Philip
http://NikitaTheSpider.com/
Whole-site HTML validation, link checking and more
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Josh Trutwin | 2007-09-24 23:51:56 | table column reordering |
| Previous Message | Rhys Stewart | 2007-09-24 23:18:31 | Re: set returning functions. |