Re: pg_restore --multi-thread

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

In response to

Responses

Browse pgsql-hackers by date

  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