Re: pg_dump slower than pg_restore

On 7/3/2014 11:47 AM, Eduardo Morras wrote:
> No, there's nothing wrong. All transparent compressed objects stored
> in database, toast, lo, etc.. is transparently decompressed while
> pg_dump access them and then you gzip it again. I don't know why it
> doesn't dump the compressed data directly.

That sounds odd, but if pg_dump decompresses the large objects and then
I gzip them on backup, doesn't the same more or less happen in reverse
when I pg_restore them?  I mean, I gunzip the backup and then pg_restore
must compress the large objects when it writes them back.

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.