Re: pg_restore --multi-thread

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
>
> Either it is using that many threads in the client, or it is using that
> many connections to the server.  I assume the implementation does
> approximately both, but we should be clear about what we promise to the
> user.  Either: Reserve this many connections on the server.  Or: Reserve
> this many threads in the kernel of the client.  The documentation in the
> reference/man page is equally confused.
>
> Also, the term "multi" is redundant, because whether it is multi or single
> is obviously determined by the value of NUM.

After reviewing the discussion and the implementation, I would say "workers" 
would be the best description of the feature, but unfortunately the options -w 
or -W are not available.  I'd also avoid -n or -N for "num..." because pg_dump 
already uses -n and -N for something else, and we are now trying to avoid 
inconsistent options between these programs.  Also, option names usually don't 
start with units (imagine --num-shared-buffers or --num-port).

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.  I also noticed that Andrew D. 
used "jobs" in his own emails to comment on the feature. :-)

The attached patch also updated the documentation to give some additional 
advice about which numbers to use.