Re: 5 minutes to pg_dump nothing

Поиск
Список
Период
Сортировка
От Nikita The Spider The Spider
Тема Re: 5 minutes to pg_dump nothing
Дата
Msg-id 35e76ac10709210958t19b0986r363dbdebe95e5f92@mail.gmail.com
обсуждение исходный текст
Ответ на Re: 5 minutes to pg_dump nothing  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: 5 minutes to pg_dump nothing  ("Nikita The Spider The Spider" <nikitathespider@gmail.com>)
Список pgsql-general
On 9/21/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Nikita The Spider The Spider" <nikitathespider@gmail.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

В списке pgsql-general по дате отправления:

Предыдущее
От: Erik Jones
Дата:
Сообщение: Migrating from 32 bit to 64 bit binaries
Следующее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: Migrating from 32 bit to 64 bit binaries