Re: How to get parallel restore in PG 8.4 to work?

Поиск
Список
Период
Сортировка
От henk de wit
Тема Re: How to get parallel restore in PG 8.4 to work?
Дата
Msg-id COL104-W101E9D4DF3EB37242C9926F5880@phx.gbl
обсуждение исходный текст
Ответ на Re: How to get parallel restore in PG 8.4 to work?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-performance
>> I still have some work to do to find out why dumping in the custom
>> format is so much slower.
>
> Offhand the only reason I can see for it to be much different from
> plain-text output is that -Fc compresses by default. If you don't
> care about that, try -Fc -Z0.

Ok, I did some performance testing today and I appeared to be wrong after all. My apologies for the noise.

Here are some test results:

Scenarioxfsjfs patchedjfs
cat backup | gunzip | psql45 min--
pg_dump> hdd (uncompressed) (==pg_dump -Fp)--10 min 15 sec
pg_dump -Fc> hdd (uncompressed)10 min 20 sec10 min 21 sec10 min 28 sec
pg_dump -Fc | gzip> hdd11 min 20 sec11 min 25 sec12 min 04 sec
pg_restore 8 threads14 min 23 sec11 min 40 sec11 min 20 sec
pg_restore 16 threads11 min 46 sec12 min 40 sec12 min 33 sec
pg_restore 32 threads11 min 42 sec12 min 30 sec12 min 30 sec

As can be seen in the table (hope this renders correctly on the mailing list), there is barely a difference between a plain dump and a custom format dump. For who it concerns, xfs performance a little better than jfs here, but the difference is marginal. More on topic, beyond 16 processes there isn't any notable speed improvement for the parallel restore (as expected).

Kind regards,
Henk


See all the ways you can stay connected to friends and family

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

Предыдущее
От: James Mansion
Дата:
Сообщение: Re: Raid 10 chunksize
Следующее
От: Scott Carey
Дата:
Сообщение: Re: Raid 10 chunksize