Re: pg_dump far too slow

От: Matthew Wakeling
Тема: Re: pg_dump far too slow
Дата: ,
Msg-id: alpine.DEB.2.00.1003181113060.1887@aragorn.flymine.org
(см: обсуждение, исходный текст)
Ответ на: pg_dump far too slow  (David Newall)
Список: pgsql-performance

Скрыть дерево обсуждения

pg_dump far too slow  (David Newall, )
 Re: pg_dump far too slow  (Tom Lane, )
  Re: pg_dump far too slow  (David Newall, )
   Re: pg_dump far too slow  (Craig Ringer, )
    Re: pg_dump far too slow  (Tom Lane, )
     Re: pg_dump far too slow  (David Newall, )
      Re: pg_dump far too slow  (Scott Carey, )
   Re: pg_dump far too slow  (Dave Crooke, )
    Re: pg_dump far too slow  (Bob Lunney, )
 Re: pg_dump far too slow  (Robert Haas, )
 Re: pg_dump far too slow  (Dave Crooke, )
 Re: pg_dump far too slow  (Matthew Wakeling, )

On Sun, 14 Mar 2010, David Newall wrote:
>   nohup time pg_dump -f database.dmp -Z9 database
>
> I presumed pg_dump was CPU-bound because of gzip compression, but a test I
> ran makes that seem unlikely...

There was some discussion about this a few months ago at
http://archives.postgresql.org/pgsql-performance/2009-07/msg00348.php

It seems that getting pg_dump to do the compression is a fair amount
slower than piping the plain format dump straight through gzip. You get a
bit more parallelism that way too.

Matthew


--
 I'm always interested when [cold callers] try to flog conservatories.
 Anyone who can actually attach a conservatory to a fourth floor flat
 stands a marginally better than average chance of winning my custom.
 (Seen on Usenet)


В списке pgsql-performance по дате сообщения:

От: Arjen van der Meijden
Дата:
Сообщение: Re: mysql to postgresql, performance questions
От: Hannu Krosing
Дата:
Сообщение: Re: Building multiple indexes concurrently