Re: pg_restore --multi-thread

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 <andrew(at)dunslane(dot)net> 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 connections
> > >>> to the server.
> > >>
> > >> How about calling it --num-connections or something like that? I
> > >> agree with Peter that "thread" is not the best terminology on
> > >> platforms where there is no threading involved.
> > >
> > > --num-workers or --num-connections would both work.
> >
> > *shrug* whatever. What should the short option be (if any?). -n is
> > taken, so -N ?
>
> Works for me.
>

yikes... -n and -N have specific meaning to pg_dump, I think keeping
consistency with that in pg_restore would be a bonus. (I still see people get
confused because -d work differently between those two apps)

Possibly -w might work, which could expand to --workers, which glosses over
the thread/process difference, is also be available for pg_dump, and has
existing mindshare with autovacuum workers.

not having a short option seems ok to me too, but I really think -N is a bad
idea.

--
Robert Treat
Conjecture: http://www.xzilla.net
Consulting: http://www.omniti.com