Re: pg_dump -j

From: Sam Stearns <sam(dot)stearns(at)dat(dot)com>
To: CONVERS Yann - DREAL Auvergne-Rhône-Alpes/CIDDAE/SIG <yann(dot)convers(at)developpement-durable(dot)gouv(dot)fr>
Cc: pgsql-admin(at)lists(dot)postgresql(dot)org, Henry Ashu <henry(dot)ashu(at)dat(dot)com>
Subject: Re: pg_dump -j
Date: 2025-11-13 15:12:17
Message-ID: CAN6TVjn=Yo=v7KpJqXDo+4O=tvjQQBAdzwR1pnHOtoh0fCDq8w@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Thanks, Yann!

On Thu, Nov 13, 2025 at 3:40 AM CONVERS Yann - DREAL
Auvergne-Rhône-Alpes/CIDDAE/SIG <yann(dot)convers(at)developpement-durable(dot)gouv(dot)fr>
wrote:

> Hi, Processeurs is on of the parameters . An other is the outpout: input
> capacity to write on disks. I purpose to test your hardware performance
> with 12 jobs to begin and test less and high to learn which is better. You
> can found it approximately
> ZjQcmQRYFpfptBannerStart
> This Message Is From an Untrusted Sender
> You have not previously corresponded with this sender.
>
> ZjQcmQRYFpfptBannerEnd
>
> Hi,
>
> Processeurs is on of the parameters . An other is the outpout:input
> capacity to write on disks.
>
> I purpose to test your hardware performance with 12 jobs to begin and test
> less and high to learn which is better.
>
> You can found it approximately with the rate of your speeding writing
> ratio on disk or outpout of LAN card factoring by job's number.
>
> But testing IRL is more efficient.
>
> We use 7 jobs for à 16 nprocs on saving on a master save dedicate to with
> car LAN 1000GhZ for example.
>
> We do it online but without clients traffic and without maintenance
> operation.
>
> Tell us wich is your better choice!
>
> Bye
>
> Yann
>
>
> Le 12/11/2025 à 17:11, > ronljohnsonjr (par Internet, dépôt
> pgsql-admin-owner+m63745-708218(at)lists(dot)postgresql(dot)org) a écrit :
>
> On Wed, Nov 12, 2025 at 10:34 AM Sam Stearns <sam(dot)stearns(at)dat(dot)com> wrote:
>
>> Howdy,
>>
>> Would someone be able to advise on the correct setting for the -j option
>> of pg_dump to run the dump in parallel, please? Is it based on CPU count,
>> or something else? The output of nproc is 32.
>>
>
> I'd certainly never go *beyond* $(nproc), but since COPY generates a lot
> of IO and compression burns through CPU, it all depends on the system's
> other workload. Only you know what your system's other workload is when
> pg_dump is running.
>
> --
> Death to <Redacted>, and butter sauce.
> Don't boil me, I'm still alive.
> <Redacted> lobster!
>
>

--

Samuel Stearns
Team Lead - Database
c: 971 762 6879 | o: 971 762 6879 | DAT.com

<https://www.dat.com/?utm_medium=email&utm_source=DAT_email_signature_link>

In response to

  • Re: pg_dump -j at 2025-11-13 08:28:15 from CONVERS Yann - DREAL Auvergne-Rhône-Alpes/CIDDAE/SIG

Browse pgsql-admin by date

  From Date Subject
Next Message Sbob 2025-11-13 17:16:54 Re: vacuumdb produces ERROR: cannot freeze committed xmax
Previous Message Fabrice Chapuis 2025-11-13 11:06:54 Re: vacuumdb produces ERROR: cannot freeze committed xmax