From: | David Wall <d(dot)wall(at)computer(dot)org> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: pg_dump slower than pg_restore |
Date: | 2014-07-04 05:51:29 |
Message-ID: | 53B640E1.2030809@computer.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Jacob Bunk Nielsen | 2014-07-04 06:41:04 | Re: pg_dump slower than pg_restore |
Previous Message | David Wall | 2014-07-04 05:43:59 | Re: pg_dump slower than pg_restore |