>> 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:
| Scenario | xfs | jfs patched | jfs |
| cat backup | gunzip | psql | 45 min | - | - |
| pg_dump> hdd (uncompressed) (==pg_dump -Fp) | - | - | 10 min 15 sec |
| pg_dump -Fc> hdd (uncompressed) | 10 min 20 sec | 10 min 21 sec | 10 min 28 sec |
| pg_dump -Fc | gzip> hdd | 11 min 20 sec | 11 min 25 sec | 12 min 04 sec |
| pg_restore 8 threads | 14 min 23 sec | 11 min 40 sec | 11 min 20 sec |
| pg_restore 16 threads | 11 min 46 sec | 12 min 40 sec | 12 min 33 sec |
| pg_restore 32 threads | 11 min 42 sec | 12 min 30 sec | 12 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
