> That's a fairly useless place to put it, though, since someone would

> only think to look at sort_mem if they already had a clue.  It should
> be mentioned under bulk data load (in performance tips chapter)

Attached is a doc patch that does this. The way I've worded it may not
be the best, though.

Neil Conway

diff --git a/doc/src/sgml/perform.sgml b/doc/src/sgml/perform.sgml
index 6b7afe2b025bf0afd01106a7a488165ef7706acd..2eaab4d0f0d28b793dcfdfb7d4de2bbb394b03c1 100644 (file)
--- a/doc/src/sgml/perform.sgml
+++ b/doc/src/sgml/perform.sgml
@@ -1,5 +1,5 @@
 
 
  
@@ -751,11 +751,10 @@ SELECT * FROM x, y, a, b, c WHERE something AND somethingelse;
 
    
     Use COPY FROM STDIN to load all the rows in one
-    command, instead of using
-    a series of INSERT commands.  This reduces parsing,
-    planning, etc.
-    overhead a great deal. If you do this then it is not necessary to turn
-    off autocommit, since it is only one command anyway.
+    command, instead of using a series of INSERT
+    commands.  This reduces parsing, planning, etc.  overhead a great
+    deal. If you do this then it is not necessary to turn off
+    autocommit, since it is only one command anyway.
    
   
 
@@ -764,9 +763,9 @@ SELECT * FROM x, y, a, b, c WHERE something AND somethingelse;
 
    
     If you are loading a freshly created table, the fastest way is to
-    create the table, bulk-load with COPY, then create any
-    indexes needed 
-    for the table.  Creating an index on pre-existing data is quicker than
+    create the table, bulk load the table's data using
+    COPY, then create any indexes needed for the
+    table.  Creating an index on pre-existing data is quicker than
     updating it incrementally as each row is loaded.
    
 
@@ -780,6 +779,19 @@ SELECT * FROM x, y, a, b, c WHERE something AND somethingelse;
    
   
 
+  
+   Increase <varname>sort_mem</varname>
+
+   
+    Temporarily increasing the sort_mem
+    configuration variable when restoring large amounts of data can
+    lead to improved performance. This is because when a B-tree index
+    is created from scratch, the existing content of the table needs
+    to be sorted. Allowing the merge sort to use more buffer pages
+    means that fewer merge passes will be required.
+   
+  
+
   
    Run <command>ANALYZE</command> Afterwards
 

diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml
index 4854d0fbaebb1fde9b7c35bbe2847ba2121a0291..4928aeda472e6f7c315b9caa2fbd82eeb6de4a9f 100644 (file)
--- a/doc/src/sgml/runtime.sgml
+++ b/doc/src/sgml/runtime.sgml
@@ -1,5 +1,5 @@
 
 
 
@@ -928,8 +928,9 @@ SET ENABLE_SEQSCAN TO OFF;
         by ORDER BY, merge joins, and CREATE INDEX.
         Hash tables are used in hash joins, hash-based aggregation, and
         hash-based processing of IN subqueries.  Because 
-        CREATE INDEX is used when restoring a database, it might
-        be good to temporarily increase this value during a restore.
+        CREATE INDEX is used when restoring a database,
+        increasing sort_mem before doing a large
+        restore operation can improve performance.