Re: parallel pg_restore - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: parallel pg_restore
Date
Msg-id 200809220953.19208.dfontaine@hi-media.com
Whole thread Raw
In response to Re: parallel pg_restore  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: parallel pg_restore  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
Le lundi 22 septembre 2008, Andrew Dunstan a écrit :
> > You'd really want the latter anyway for some cases, ie, when you don't
> > want the restore trying to hog the machine.  Maybe the right form for
> > the extra option is just a limit on how many connections to use.  Set it
> > to one to force the exact restore order, and to other values to throttle
> > how much of the machine the restore tries to eat.
>
> My intention is to have single-thread restore remain the default, at
> least for this go round, and have the user be able to choose
> --multi-thread=nn to specify the number of concurrent connections to use.

What about the make famous -j option?
      -j [jobs], --jobs[=jobs]           Specifies the number of jobs (commands) to run simultaneously.  If
there is  more than one -j option, the last one is effective.  If           the -j option is given without an argument,
make will  not  limit           the number of jobs that can run simultaneously. 

Regards,
--
dim

pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Toasted table not deleted when no out of line columns left
Next
From: Greg Smith
Date:
Subject: Initial prefetch performance testing