From ca8e3a51a05b1265f36f82497b039d7783c3dd98 Mon Sep 17 00:00:00 2001
From: Bruce Momjian <bruce@momjian.us>
Date: Fri, 26 Feb 2010 02:31:52 +0000
Subject: [PATCH] Document pg_restore --jobs as a performance enhancement.

---
 doc/src/sgml/perform.sgml | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/doc/src/sgml/perform.sgml b/doc/src/sgml/perform.sgml
index 1a9f7c1452..02c5071d2a 100644
--- a/doc/src/sgml/perform.sgml
+++ b/doc/src/sgml/perform.sgml
@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/perform.sgml,v 1.73 2010/01/15 09:18:59 heikki Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/perform.sgml,v 1.74 2010/02/26 02:31:52 momjian Exp $ -->
 
  <chapter id="performance-tips">
   <title>Performance Tips</title>
@@ -1027,7 +1027,10 @@ SELECT * FROM x, y, a, b, c WHERE something AND somethingelse;
        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.
+       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>
-- 
2.40.0