Add a couple of notes pointing out that GIN index build time is very
authorTom Lane
Fri, 16 Nov 2007 03:23:07 +0000 (03:23 +0000)
committerTom Lane
Fri, 16 Nov 2007 03:23:07 +0000 (03:23 +0000)
sensitive to maintenance_work_mem (something I just learned the hard
way).

doc/src/sgml/gin.sgml
doc/src/sgml/textsearch.sgml

index 61a3f0f4ec126c36258260ed624ec8c49d03dfca..1b7f105ac569e9a40b9e447a3dac3b5ab427e471 100644 (file)
@@ -1,4 +1,4 @@
-
+
 
 
 GIN Indexes
    
   
 
+  
+   
+   
+    
+     Build time for a GIN index is very sensitive to
+     the maintenance_work_mem setting; it doesn't pay to
+     skimp on work memory during index creation.
+    
+   
+  
+
   
    
    
     
     
      To facilitate controlled execution of such queries
-     GIN has a configurable soft upper limit on the size
-     of the returned set, the
+     GIN has a configurable soft upper limit on the
+     number of rows returned, the
      gin_fuzzy_search_limit configuration parameter.
      It is set to 0 (meaning no limit) by default.
      If a non-zero limit is set, then the returned set is a subset of
index 0a153c465cda2ee9f032d96c44ac9175df9f5e05..b43872cca5c3898f2dc790a3e8ddc0b1eb923953 100644 (file)
@@ -1,4 +1,4 @@
-
+
 
 
  Full Text Search
@@ -3256,6 +3256,13 @@ EXPLAIN SELECT * FROM apod WHERE textsearch @@ to_tsquery('supernovae');
    lexemes better but are slower to update.
   
 
+  
+   Note that GIN index build time can often be improved
+   by increasing , while
+   GiST index build time is not sensitive to that
+   parameter.
+  
+
   
    Partitioning of big collections and the proper use of GiST and GIN indexes
    allows the implementation of very fast searches with online update.