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-21 16:58:51 |
Message-ID: | 35e76ac10709210958t19b0986r363dbdebe95e5f92@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 9/21/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Nikita The Spider The Spider" <nikitathespider(at)gmail(dot)com> writes:
> > I'm seeing a problem where pg_dump takes at least 5 minutes to execute
> > no matter what I ask it to dump -- even a non-existent or empty table.
> > One possible red flag is that pg_type contains 56508 rows. This
> > doesn't seem excessive to me, but perhaps it should.
>
> That does seem like a lot --- what sort of types are they? Scalar,
> composite, what? It's fairly likely that no one has tried to optimize
> pg_dump for such a case.
Aha, thanks. Didn't realize I was pushing the bounds of what was
reasonable. Here's the type counts:
typrelkind | the_count
------------+-----------
| 114
sequence | 11496
composite | 12290
ordinary | 13844
TOAST | 9215
view | 9699
(6 rows)
> It'd be helpful if you could recompile pg_dump with profiling enabled
> (-pg compiler switch) and get a gprof profile to show where the time
> is going.
Will do. I'm going to try to recreate the problem in my development
environment where I have a bit more freedom to tinker.
--
Philip
http://NikitaTheSpider.com/
Whole-site HTML validation, link checking and more
From | Date | Subject | |
---|---|---|---|
Next Message | Joshua D. Drake | 2007-09-21 16:59:55 | Re: Migrating from 32 bit to 64 bit binaries |
Previous Message | Erik Jones | 2007-09-21 16:52:11 | Migrating from 32 bit to 64 bit binaries |