Re: parallel pg_restore
От | Dimitri Fontaine |
---|---|
Тема | Re: parallel pg_restore |
Дата | |
Msg-id | 200809220953.19208.dfontaine@hi-media.com обсуждение исходный текст |
Ответ на | Re: parallel pg_restore (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: parallel pg_restore
|
Список | 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 по дате отправления: