Re: pg_dump and pg_restore with multiple streams does Not seem to improve overall times

From: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
To: "Susan K(dot) McClure" <smcclure(at)rice(dot)edu>
Cc: "pgsql-admin(at)postgresql(dot)org" <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-01 15:49:12
Message-ID: CAOR=d=1OJQfkmygTDL_eVWMAEkFJbsvWb3=+QSf+g5Ct8T1ToQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

On Fri, May 1, 2015 at 9:16 AM, Susan K. McClure <smcclure(at)rice(dot)edu> 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? I'd 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 you've got a really fast IO subsystem increasing
the --jobs doesn't 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.

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Keith 2015-05-01 20:47:32 Re: pg_dump and pg_restore with multiple streams does Not seem to improve overall times
Previous Message Scott Whitney 2015-05-01 15:29:33 Re: pg_dump and pg_restore with multiple streams does Not seem to improve overall times