Add a couple of notes pointing out that GIN index build time is very

sensitive to maintenance_work_mem (something I just learned the hard
way).

doc/src/sgml/gin.sgml

-<!-- $PostgreSQL: pgsql/doc/src/sgml/gin.sgml,v 2.12 2007/11/13 23:36:26 tgl Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/gin.sgml,v 2.13 2007/11/16 03:23:07 tgl Exp $ -->
 
 <chapter id="GIN">
 <title>GIN Indexes</title>
@@ -161,6 +161,17 @@
    </listitem>
   </varlistentry>
 
+  <varlistentry>
+   <term><xref linkend="guc-maintenance-work-mem"></term>
+   <listitem>
+    <para>
+     Build time for a <acronym>GIN</acronym> index is very sensitive to
+     the <varname>maintenance_work_mem</> setting; it doesn't pay to
+     skimp on work memory during index creation.
+    </para>
+   </listitem>
+  </varlistentry>
+
   <varlistentry>
    <term><xref linkend="guc-gin-fuzzy-search-limit"></term>
    <listitem>
@@ -177,8 +188,8 @@
     </para>
     <para>
      To facilitate controlled execution of such queries
-     <acronym>GIN</acronym> has a configurable soft upper limit on the size
-     of the returned set, the
+     <acronym>GIN</acronym> has a configurable soft upper limit on the
+     number of rows returned, the
      <varname>gin_fuzzy_search_limit</varname> 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

doc/src/sgml/textsearch.sgml

-<!-- $PostgreSQL: pgsql/doc/src/sgml/textsearch.sgml,v 1.35 2007/11/14 23:48:55 tgl Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/textsearch.sgml,v 1.36 2007/11/16 03:23:07 tgl Exp $ -->
 
 <chapter id="textsearch">
  <title id="textsearch-title">Full Text Search</title>
@@ -3256,6 +3256,13 @@ EXPLAIN SELECT * FROM apod WHERE textsearch @@ to_tsquery('supernovae');
    lexemes better but are slower to update.
   </para>
 
+  <para>
+   Note that <acronym>GIN</acronym> index build time can often be improved
+   by increasing <xref linkend="guc-maintenance-work-mem">, while
+   <acronym>GiST</acronym> index build time is not sensitive to that
+   parameter.
+  </para>
+
   <para>
    Partitioning of big collections and the proper use of GiST and GIN indexes
    allows the implementation of very fast searches with online update.