Re: pg_restore --multi-thread

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Cédric Villemain <cedric(dot)villemain(at)dalibo(dot)com>, jd(at)commandprompt(dot)com, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_restore --multi-thread
Date: 2009-02-20 12:32:05
Message-ID: 499EA2C5.50705@gmx.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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?

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2009-02-20 13:31:49 Password prompting business
Previous Message Heikki Linnakangas 2009-02-20 12:02:26 Re: GIN fast insert