Re: parallel pg_restore
От | Simon Riggs |
---|---|
Тема | Re: parallel pg_restore |
Дата | |
Msg-id | 1222199639.4445.462.camel@ebony.2ndQuadrant обсуждение исходный текст |
Ответ на | Re: parallel pg_restore (Joshua Drake <jd@commandprompt.com>) |
Ответы |
Re: parallel pg_restore
|
Список | pgsql-hackers |
On Tue, 2008-09-23 at 12:43 -0700, Joshua Drake wrote: > On Tue, 23 Sep 2008 08:44:19 +0100 > Simon Riggs <simon@2ndQuadrant.com> wrote: > > > > > On Mon, 2008-09-22 at 15:05 -0400, Andrew Dunstan wrote: > > > > > j and m happen to be two of those that are available. > > > > > > I honestly don't have a terribly strong opinion about what it > > > should be called. I can live with jobs or multi-threads. > > > > Perhaps we can use -j for jobs and -m for memory, so we can set memory > > available across all threads with a single total value. > > > > I can live with jobs or multi-threads also, whichever we decide. > > Neither one is confusing to explain. > > > > Memory? Where did that come from. Andrew is that in your spec? No, but it's in mine. As I said upthread, no point in making it more parallel than memory allows. Different operations need more/less memory than others, so we must think about that also. We can quickly work out how big a table is, so we can work out how much memory it will need to perform sorts for index builds and thus how many parallel builds can sensibly take place. -- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
В списке pgsql-hackers по дате отправления: