Re: pg_dump slower than pg_restore

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg_dump slower than pg_restore
Дата
Msg-id 19743.1404483578@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pg_dump slower than pg_restore  (David Wall <d.wall@computer.org>)
Ответы Re: pg_dump slower than pg_restore  (David Wall <d.wall@computer.org>)
Список pgsql-general
David Wall <d.wall@computer.org> writes:
> It just seems odd that pg_dump is slower than pg_restore to me. Most
> grumblings I read about suggest that pg_restore is too slow.

> I have noted that the last split file segment will often appear to be
> done -- no file modifications -- while pg_dump is still running, often
> for another 20 minutes or so, and then some last bit is finally
> written.  It's as if pg_dump is calculating something at the end that is
> quite slow.  At startup, there's a delay before data is written, too,
> but it's generally 1-2 minutes at most.

You haven't given us much info about the contents of this database.
Are there a lot of tables? functions? large objects?  How many is
"a lot", if so?

I'm suspicious that you're paying a penalty associated with pg_dump's
rather inefficient handling of metadata for large objects, but there's
not enough info in this thread to diagnose it.  It'd be very interesting
to see perf or oprofile stats on the pg_dump run, particularly during
the parts where it doesn't seem to be writing anything.

            regards, tom lane


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

Предыдущее
От: hubert depesz lubaczewski
Дата:
Сообщение: Re: Random-looking primary keys in the range 100000..999999
Следующее
От: Kynn Jones
Дата:
Сообщение: Re: Random-looking primary keys in the range 100000..999999