fast, an update
   that causes the pending list to become <quote>too large</quote> will incur an
   immediate cleanup cycle and thus be much slower than other updates.
   Proper use of autovacuum can minimize both of these problems.
  </para>

  <para>
   If consistent response time is more important than update speed,
   use of pending entries can be disabled by turning off the
   <literal>fastupdate</literal> storage parameter for a
   <acronym>GIN</acronym> index.  See <xref linkend="sql-createindex"/>
   for details.
  </para>
 </sect3>

 <sect3 id="gin-partial-match">
  <title>Partial Match Algorithm</title>

  <para>
   GIN can support <quote>partial match</quote> queries, in which the query
   does not determine an exact match for one or more keys, but the possible
   matches fall within a reasonably narrow range of key values (within the
   key sorting order determined by the <function>compare</function> support method).
   The <function>extractQuery</function> method, instead of returning a key value
   to be matched exactly, returns a key value that is the lower bound of
   the range to be searched, and sets the <literal>pmatch</literal> flag true.
   The key range is then scanned using the <function>comparePartial</function>
   method.  <function>comparePartial</function> must return zero for a matching
   index key, less than zero for a non-match that is still within the range
   to be searched, or greater than zero if the index key is past the range
   that could match.
  </para>
 </sect3>

</sect2>

<sect2 id="gin-tips">
<title>GIN Tips and Tricks</title>

 <variablelist>
  <varlistentry>
   <term>Create vs. insert</term>
   <listitem>
    <para>
     Insertion into a <acronym>GIN</acronym> index can be slow
     due to the likelihood of many keys being inserted for each item.
     So, for bulk insertions into a table it is advisable to drop the GIN
     index and recreate it after finishing bulk insertion.
    </para>

    <para>
     When <literal>fastupdate</literal> is enabled for <acronym>GIN</acronym>
     (see <xref linkend="gin-fast-update"/> for details), the penalty is
     less than when it is not.  But for very large updates it may still be
     best to drop and recreate the index.
    </para>
   </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</varname> setting; it doesn't pay to
     skimp on work memory during index creation.
    </para>
   </listitem>
  </varlistentry>

  <varlistentry>
   <term><xref linkend="guc-gin-pending-list-limit"/></term>
   <listitem>
    <para>
     During a series of insertions into an existing <acronym>GIN</acronym>
     index that has <literal>fastupdate</literal> enabled, the system will clean up
     the pending-entry list whenever the list grows larger than
     <varname>gin_pending_list_limit</varname>. To avoid fluctuations in observed
     response time, it's desirable to have pending-list cleanup occur in the
     background (i.e., via autovacuum).  Foreground cleanup operations
     can be avoided by increasing <varname>gin_pending_list_limit</varname>
     or making autovacuum more aggressive.
     However, enlarging the threshold of the cleanup operation means that
     if a foreground cleanup does occur, it will take even longer.
    </para>
    <para>
     <varname>gin_pending_list_limit</varname> can be overridden