Re: pgsql: pg_restore -jN does not equate "multiple jobs", so partly revert
От | Bruce Momjian |
---|---|
Тема | Re: pgsql: pg_restore -jN does not equate "multiple jobs", so partly revert |
Дата | |
Msg-id | 201002260232.o1Q2WIG27946@momjian.us обсуждение исходный текст |
Ответ на | Re: pgsql: pg_restore -jN does not equate "multiple jobs", so partly revert (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: pgsql: pg_restore -jN does not equate "multiple
jobs", so partly revert
|
Список | pgsql-committers |
Simon Riggs wrote: > > On Tue, 2009-04-14 at 00:06 +0000, Alvaro Herrera wrote: > > Log Message: > > ----------- > > pg_restore -jN does not equate "multiple jobs", so partly revert the > > previous patch. > > I notice that the release notes talk about "parallel restore", yet the > word parallel is not used in the docs anywhere. The section on restoring > a dump makes no mention of this new facility, nor does the perf tips > section. > > Also says that the option doesn't work with --single-transaction, so we > should say that you've added in TRUNCATE to make the COPY go faster (or > haven't you? I know we discussed it). Good point. Documentation patch attached and applied. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do + If your life is a hard drive, Christ can be your backup. + Index: doc/src/sgml/perform.sgml =================================================================== RCS file: /cvsroot/pgsql/doc/src/sgml/perform.sgml,v retrieving revision 1.73 diff -c -c -r1.73 perform.sgml *** doc/src/sgml/perform.sgml 15 Jan 2010 09:18:59 -0000 1.73 --- doc/src/sgml/perform.sgml 26 Feb 2010 02:31:28 -0000 *************** *** 1027,1033 **** possibly discarding many hours of processing. Depending on how interrelated the data is, that might seem preferable to manual cleanup, or not. <command>COPY</> commands will run fastest if you use a single ! transaction and have WAL archiving turned off. </para> </listitem> <listitem> --- 1027,1036 ---- possibly discarding many hours of processing. Depending on how interrelated the data is, that might seem preferable to manual cleanup, or not. <command>COPY</> commands will run fastest if you use a single ! transaction and have WAL archiving turned off. ! <application>pg_restore</> also has a <option>--jobs</> option ! which allows concurrent data loading and index creation, and has ! the performance advantages of doing COPY in a single transaction. </para> </listitem> <listitem>
В списке pgsql-committers по дате отправления: