Re: pg_restore --multi-thread - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: pg_restore --multi-thread
Date
Msg-id 49944A73.6030206@dunslane.net
Whole thread Raw
In response to pg_restore --multi-thread  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: pg_restore --multi-thread
Re: pg_restore --multi-thread
List pgsql-hackers

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.
>
>   


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.

I'm not sure what you mean about reserving threads in the client kernel.

I also don't really understand what is confusing about the description.

cheers

andrew


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Writing and Reading bytea
Next
From: Tom Lane
Date:
Subject: Re: WIP: hooking parser