From: | Jan Lentfer <Jan(dot)Lentfer(at)web(dot)de> |
---|---|
To: | <pgsql-admin(at)postgresql(dot)org> |
Subject: | Re: pg_dump and pg_restore with multiple streams does Not seem to improve overall times |
Date: | 2015-05-04 12:14:01 |
Message-ID: | d2d0b6691081e6e714f61d9d9db39a13@imap.lan.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
Am 2015-05-01 17:49, schrieb Scott Marlowe:
> On Fri, May 1, 2015 at 9:16 AM, Susan K. McClure <smcclure(at)rice(dot)edu
> [1]> wrote:
>
>> Running postgresql 9-4 on REHL 7 system. I am trying to speed up
>> pg_dump and pg_restore by
>> using a postgresql.conf with various performance options set, and
>> the --jobs option to force multiple
>> streams. But various tests, with various "--jobs=" numbers only
>> achieve at most a 1 minute improvement
>> in elapsed time versus doing pg_dump or pg_restore with no "--jobs"
>> option and no postgresql.conf with performance
>> options. Am I missing some key option(s) to improve things??
>>
>> The DB in question is ~25GB. The processor has 24 Cpus, 12 cores
>>
>> I have tried with "--jobs = 8, 12, and 20" with little or no
>> discernible improvements.
>
> So have you tried 2 jobs first? Id see how 1, 2, 3, 4 etc work. See
> if
> 2 is faster than 1, then 3 faster than 2 etc.
>
> Most of the time, unless youve got a really fast IO subsystem
> increasing the --jobs doesnt make a big difference as a lot of the
> work is sequential. Also on restores I think the extra jobs part only
> kicks in for index builds.
It does parallel COPY, too.
Jan
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Lentfer | 2015-05-04 12:17:14 | Re: pg_dump and pg_restore with multiple streams does Not seem to improve overall times |
Previous Message | Daniel Verite | 2015-05-02 17:57:17 | Re: [GENERAL] How to exclude blobs (large objects) from being loaded by pg_restore? |