Re: pgsql: pg_restore -jN does not equate "multiple jobs", so partly revert - Mailing list pgsql-committers

From Bruce Momjian
Subject Re: pgsql: pg_restore -jN does not equate "multiple jobs", so partly revert
Date
Msg-id 201002260232.o1Q2WIG27946@momjian.us
Whole thread Raw
In response to Re: pgsql: pg_restore -jN does not equate "multiple jobs", so partly revert  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: pgsql: pg_restore -jN does not equate "multiple jobs", so partly revert  (Simon Riggs <simon@2ndQuadrant.com>)
List 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 by date:

Previous
From: momjian@postgresql.org (Bruce Momjian)
Date:
Subject: pgsql: Document pg_restore --jobs as a performance enhancement.
Next
From: Andrew Dunstan
Date:
Subject: Re: pgsql: Add pgindent typedefs file to CVS.