<type>tsvector</type> values, and not their weight labels.  Thus a table
   row recheck is needed when using a query that involves weights.
  </para>

  <para>
   A GiST index is <firstterm>lossy</firstterm>, meaning that the index
   might produce false matches, and it is necessary
   to check the actual table row to eliminate such false matches.
   (<productname>PostgreSQL</productname> does this automatically when needed.)
   GiST indexes are lossy because each document is represented in the
   index by a fixed-length signature.  The signature length in bytes is determined
   by the value of the optional integer parameter <literal>siglen</literal>.
   The default signature length (when <literal>siglen</literal> is not specified) is
   124 bytes, the maximum signature length is 2024 bytes. The signature is generated by hashing
   each word into a single bit in an n-bit string, with all these bits OR-ed
   together to produce an n-bit document signature.  When two words hash to
   the same bit position there will be a false match.  If all words in
   the query have matches (real or false) then the table row must be
   retrieved to see if the match is correct.  Longer signatures lead to a more
   precise search (scanning a smaller fraction of the index and fewer heap
   pages), at the cost of a larger index.
  </para>

  <para>
   A GiST index can be covering, i.e., use the <literal>INCLUDE</literal>
   clause.  Included columns can have data types without any GiST operator
   class.  Included attributes will be stored uncompressed.
  </para>

  <para>
   Lossiness causes performance degradation due to unnecessary fetches of table
   records that turn out to be false matches.  Since random access to table
   records is slow, this limits the usefulness of GiST indexes.  The
   likelihood of false matches depends on several factors, in particular the
   number of unique words, so using dictionaries to reduce this number is
   recommended.
  </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 GIN and GiST indexes
   allows the implementation of very fast searches with online update.
   Partitioning can be done at the database level using table inheritance,
   or by distributing documents over
   servers and collecting external search results, e.g., via <link
   linkend="ddl-foreign-data">Foreign Data</link> access.
   The latter is possible because ranking functions use
   only local information.
  </para>

 </sect1>

 <sect1 id="textsearch-psql">
  <title><application>psql</application> Support</title>

  <para>
   Information about text search configuration objects can be obtained
   in <application>psql</application> using a set of commands:
<synopsis>
\dF{d,p,t}<optional>+</optional> <optional>PATTERN</optional>
</synopsis>
   An optional <literal>+</literal> produces more details.
  </para>

  <para>
   The optional parameter <replaceable>PATTERN</replaceable> can be the name of
   a text search object, optionally schema-qualified.  If
   <replaceable>PATTERN</replaceable> is omitted then information about all
   visible objects will be displayed.  <replaceable>PATTERN</replaceable> can be a
   regular expression and can provide <emphasis>separate</emphasis> patterns
   for the schema and object names.  The following examples illustrate this:

<screen>
=&gt; \dF *fulltext*
       List of text search configurations
 Schema |  Name        | Description
--------+--------------+-------------
 public | fulltext_cfg |
</screen>

<screen>
=&gt; \dF *.fulltext*
       List of text search configurations
 Schema   |  Name        | Description
----------+----------------------------
 fulltext | fulltext_cfg |
 public   | fulltext_cfg |
</screen>

   The available commands