Peter Eisentraut wrote:
While I think "jobs" isn't a totally accurate description, I would still
propose to use -j/--jobs for the option name, because it is neutral about the
implementation and has a strong precedent as being used to increase the
parallelization to get the work done faster.
On Thursday 12 February 2009 17:41:01 Peter Eisentraut wrote:
> I know we've already had a discussion on the naming of the pg_restore -m
> option, but in any case this description in pg_restore --help is confusing:
>
> -m, --multi-thread=NUM use this many parallel connections to restore
>
> Eithe
On Fri, 2009-02-20 at 11:57 -0600, Kevin Grittner wrote:
>
> > But you are right that there isn't a simple formula.
>
> Perhaps the greater of the number of CPUs or effective spindles?
>
> (24 sounds suspiciously close to effective spindles on a 50 spindle
> box
> with RAID 10.)
It does exce
>>> Andrew Dunstan wrote:
> Joshua D. Drake wrote:
>> the fastest restore time for
>> 220G was performed with 24 threads with an 8 core box.
>> It is important to point out that this was a machine with 50
spindles.
>> Which is where your bottleneck is going to be immediately after
solving
>> th
On Fri, Feb 20, 2009 at 09:22:58AM -0800, Joshua D. Drake wrote:
> On Fri, 2009-02-20 at 09:33 -0500, Andrew Dunstan wrote:
>
> > 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 hones
Joshua D. Drake wrote:
On Fri, 2009-02-20 at 09:33 -0500, Andrew Dunstan wrote:
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 a
On Fri, 2009-02-20 at 09:33 -0500, Andrew Dunstan wrote:
> 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 in
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.
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 e
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 descripti
On Mon, Feb 16, 2009 at 12:10 PM, Cédric Villemain
wrote:
>>
>> is -j already affected ?
>
> else (like make):
>
> -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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Cédric Villemain a écrit :
> Joshua D. Drake a écrit :
>> On Thu, 2009-02-12 at 11:47 -0500, Andrew Dunstan wrote:
>>> Joshua D. Drake wrote:
On Thu, 2009-02-12 at 11:32 -0500, Tom Lane wrote:
> Andrew Dunstan writes:
>
>
On Thursday 12 February 2009 11:50:26 Joshua D. Drake wrote:
> On Thu, 2009-02-12 at 11:47 -0500, Andrew Dunstan wrote:
> > Joshua D. Drake wrote:
> > > On Thu, 2009-02-12 at 11:32 -0500, Tom Lane wrote:
> > >> Andrew Dunstan writes:
> > >>> The implementation is actually different across platform
Andrew Dunstan wrote:
I also don't really understand what is confusing about the description.
Where does the benefit of using it come from? When would one want to
use it? Is it because the parallelization happens on the client or on
the server? Does it happen because to CPU parallelization
On Thu, Feb 12, 2009 at 02:16:39PM -0500, Michael Glaesemann wrote:
>
> On 2009-02-12, at 14:15 , Jonah H. Harris wrote:
>
>> On Thu, Feb 12, 2009 at 11:37 AM, Joshua D. Drake > >wrote:
>>
>>> --num-workers or --num-connections would both work.
>>
>> --num-parallel?
>
> --num-concurrent?
--num-bik
On 2009-02-12, at 14:15 , Jonah H. Harris wrote:
On Thu, Feb 12, 2009 at 11:37 AM, Joshua D. Drake >wrote:
--num-workers or --num-connections would both work.
--num-parallel?
--num-concurrent?
Michael Glaesemann
michael.glaesem...@myyearbook.com
--
Sent via pgsql-hackers mailing list
On Thu, Feb 12, 2009 at 11:37 AM, Joshua D. Drake wrote:
> --num-workers or --num-connections would both work.
--num-parallel?
--
Jonah H. Harris, Senior DBA
myYearbook.com
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Joshua D. Drake a écrit :
> On Thu, 2009-02-12 at 11:47 -0500, Andrew Dunstan wrote:
>> Joshua D. Drake wrote:
>>> On Thu, 2009-02-12 at 11:32 -0500, Tom Lane wrote:
>>>
Andrew Dunstan writes:
> The implementation is actually dif
On Thu, 2009-02-12 at 11:47 -0500, Andrew Dunstan wrote:
>
> Joshua D. Drake wrote:
> > On Thu, 2009-02-12 at 11:32 -0500, Tom Lane wrote:
> >
> >> Andrew Dunstan writes:
> >>
> >>> The implementation is actually different across platforms: on Windows
> >>> the workers are genuine thread
Joshua D. Drake wrote:
On Thu, 2009-02-12 at 11:32 -0500, Tom Lane wrote:
Andrew Dunstan writes:
The implementation is actually different across platforms: on Windows
the workers are genuine threads, while elsewhere they are forked
children in the same fashion as the backend (non-EX
On Thu, 2009-02-12 at 11:32 -0500, Tom Lane wrote:
> Andrew Dunstan writes:
> > The implementation is actually different across platforms: on Windows
> > the workers are genuine threads, while elsewhere they are forked
> > children in the same fashion as the backend (non-EXEC_BACKEND case). In
Andrew Dunstan writes:
> The implementation is actually different across platforms: on Windows
> the workers are genuine threads, while elsewhere they are forked
> children in the same fashion as the backend (non-EXEC_BACKEND case). In
> either case, the program will use up to NUM concurrent co
Peter Eisentraut wrote:
I know we've already had a discussion on the naming of the pg_restore -m
option, but in any case this description in pg_restore --help is confusing:
-m, --multi-thread=NUM use this many parallel connections to restore
Either it is using that many threads in the clie
I know we've already had a discussion on the naming of the pg_restore -m
option, but in any case this description in pg_restore --help is confusing:
-m, --multi-thread=NUM use this many parallel connections to restore
Either it is using that many threads in the client, or it is using that many
24 matches
Mail list logo
