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?
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 |