From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(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 14:33:11 |
Message-ID: | 499EBF27.1050107@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-02-20 15:59:03 | Re: Optimization rules for semi and anti joins |
Previous Message | Gregory Stark | 2009-02-20 14:19:31 | Re: WIP: hooking parser |