Re: 5 minutes to pg_dump nothing

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

In response to

Responses

Browse pgsql-general by date

  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