Peter Eisentraut wrote:
> Andrew Dunstan wrote:
>> Cédric Villemain wrote:
>>>
>>> -j [jobs], --jobs[=jobs]
>>> Specifies the number of jobs (pg_restore) to run
>>> simultaneously. If the -j
>>> option is given without an argument, pg_restore will not limit the
>>> number of
>>> jobs that can run simultaneously.
>
>> Quite apart from anything else, this description is almost 100% dead
>> wrong. The argument is not optional at all, and there is no
>> unlimited parallelism. If you want to know how it actually works look
>> at the dev docs.
>
> What I'm still missing here is a piece of documentation or a guideline
> that says when a given number of threads/jobs/workers would be
> appropriate. For make -j, this is pretty clear: If you have N CPUs to
> spare, use -j N. For pg_restore, this is not made clear: Is it the
> number of CPUs on the client or the server or the number of disks on
> the client or the server or perhaps a combination of this or something
> else?
The short answer is that we don't know yet. There is anecdotal evidence
that the number of CPUs on the server is a good place to start, but we
should be honest enough to say that this is a new feature and we are
still gathering information about its performance. If you want to give
some advice, then I think the best advice is to try a variety of
settings to see what works best for you, and if you have a good set of
figures report it back to us.
cheers
andrew