From: | Bosco Rama <postgres(at)boscorama(dot)com> |
---|---|
To: | David Wall <d(dot)wall(at)computer(dot)org>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: pg_dump slower than pg_restore |
Date: | 2014-07-04 00:13:27 |
Message-ID: | 53B5F1A7.3020104@boscorama.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 07/03/14 16:51, David Wall wrote:
>
> On 7/3/2014 10:36 AM, Bosco Rama wrote:
>> If those large objects are 'files' that are already compressed (e.g.
>> most image files and pdf's) you are spending a lot of time trying to
>> compress the compressed data ... and failing.
>>
>> Try setting the compression factor to an intermediate value, or even
>> zero (i.e. no dump compression). For example, to get the 'low hanging
>> fruit' compressed:
>> $ pg_dump -Z1 -Fc ...
>>
>> IIRC, the default value of '-Z' is 6.
>>
>> As usual your choice will be a run-time vs file-size trade-off so try
>> several values for '-Z' and see what works best for you.
>
> That's interesting. Since I gzip the resulting output, I'll give -Z0 a
> try. I didn't realize that any compression was on by default.
If you use gzip you will be doing the same 'possibly unnecessary'
compression step. Use a similar approach to the gzip command as you
would for the pg_dump command. That is, use one if the -[0-9] options,
like this:
$ pg_dump -Z0 -Fc ... | gzip -[0-9] ...
> Thanks for the tip...
NP.
HTH,
Bosco.
From | Date | Subject | |
---|---|---|---|
Next Message | Bosco Rama | 2014-07-04 00:13:52 | Re: pg_dump slower than pg_restore |
Previous Message | sunpeng | 2014-07-04 00:10:56 | Re: which odbc version (32 or 64 bit) should be installed in Client ? |