Re: pg_dump and pg_restore with multiple streams does Not seem to improve overall times
От | Jan Lentfer |
---|---|
Тема | Re: pg_dump and pg_restore with multiple streams does Not seem to improve overall times |
Дата | |
Msg-id | d2d0b6691081e6e714f61d9d9db39a13@imap.lan.net обсуждение исходный текст |
Ответ на | Re: pg_dump and pg_restore with multiple streams does Not seem to improve overall times (Scott Marlowe <scott.marlowe@gmail.com>) |
Список | pgsql-admin |
Am 2015-05-01 17:49, schrieb Scott Marlowe: > On Fri, May 1, 2015 at 9:16 AM, Susan K. McClure <smcclure@rice.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
В списке pgsql-admin по дате отправления: