Current File : //opt/alt/postgresql11/usr/share/doc/alt-postgresql11-9.2.24/html/textsearch-indexes.html
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML
><HEAD
><TITLE
>GiST and GIN Index Types</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
REV="MADE"
HREF="mailto:pgsql-docs@postgresql.org"><LINK
REL="HOME"
TITLE="PostgreSQL 9.2.24 Documentation"
HREF="index.html"><LINK
REL="UP"
TITLE="Full Text Search"
HREF="textsearch.html"><LINK
REL="PREVIOUS"
TITLE="Testing and Debugging Text Search"
HREF="textsearch-debugging.html"><LINK
REL="NEXT"
TITLE="psql Support"
HREF="textsearch-psql.html"><LINK
REL="STYLESHEET"
TYPE="text/css"
HREF="stylesheet.css"><META
HTTP-EQUIV="Content-Type"
CONTENT="text/html; charset=ISO-8859-1"><META
NAME="creation"
CONTENT="2017-11-06T22:43:11"></HEAD
><BODY
CLASS="SECT1"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="5"
ALIGN="center"
VALIGN="bottom"
><A
HREF="index.html"
>PostgreSQL 9.2.24 Documentation</A
></TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="top"
><A
TITLE="Testing and Debugging Text Search"
HREF="textsearch-debugging.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="top"
><A
HREF="textsearch.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="60%"
ALIGN="center"
VALIGN="bottom"
>Chapter 12. Full Text Search</TD
><TD
WIDTH="20%"
ALIGN="right"
VALIGN="top"
><A
TITLE="psql Support"
HREF="textsearch-psql.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="TEXTSEARCH-INDEXES"
>12.9. GiST and GIN Index Types</A
></H1
><P
> There are two kinds of indexes that can be used to speed up full text
searches.
Note that indexes are not mandatory for full text searching, but in
cases where a column is searched on a regular basis, an index is
usually desirable.
<P
></P
></P><DIV
CLASS="VARIABLELIST"
><DL
><DT
><PRE
CLASS="SYNOPSIS"
>CREATE INDEX <TT
CLASS="REPLACEABLE"
><I
>name</I
></TT
> ON <TT
CLASS="REPLACEABLE"
><I
>table</I
></TT
> USING gist(<TT
CLASS="REPLACEABLE"
><I
>column</I
></TT
>);</PRE
></DT
><DD
><P
> Creates a GiST (Generalized Search Tree)-based index.
The <TT
CLASS="REPLACEABLE"
><I
>column</I
></TT
> can be of <TT
CLASS="TYPE"
>tsvector</TT
> or
<TT
CLASS="TYPE"
>tsquery</TT
> type.
</P
></DD
><DT
><PRE
CLASS="SYNOPSIS"
>CREATE INDEX <TT
CLASS="REPLACEABLE"
><I
>name</I
></TT
> ON <TT
CLASS="REPLACEABLE"
><I
>table</I
></TT
> USING gin(<TT
CLASS="REPLACEABLE"
><I
>column</I
></TT
>);</PRE
></DT
><DD
><P
> Creates a GIN (Generalized Inverted Index)-based index.
The <TT
CLASS="REPLACEABLE"
><I
>column</I
></TT
> must be of <TT
CLASS="TYPE"
>tsvector</TT
> type.
</P
></DD
></DL
></DIV
><P>
</P
><P
> There are substantial performance differences between the two index types,
so it is important to understand their characteristics.
</P
><P
> A GiST index is <I
CLASS="FIRSTTERM"
>lossy</I
>, meaning that the index
may produce false matches, and it is necessary
to check the actual table row to eliminate such false matches.
(<SPAN
CLASS="PRODUCTNAME"
>PostgreSQL</SPAN
> does this automatically when needed.)
GiST indexes are lossy because each document is represented in the
index by a fixed-length signature. 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.
</P
><P
> 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.
</P
><P
> GIN indexes are not lossy for standard queries, but their performance
depends logarithmically on the number of unique words.
(However, GIN indexes store only the words (lexemes) of <TT
CLASS="TYPE"
>tsvector</TT
>
values, and not their weight labels. Thus a table row recheck is needed
when using a query that involves weights.)
</P
><P
> In choosing which index type to use, GiST or GIN, consider these
performance differences:
<P
></P
></P><UL
COMPACT="COMPACT"
><LI
STYLE="list-style-type: disc"
><P
> GIN index lookups are about three times faster than GiST
</P
></LI
><LI
STYLE="list-style-type: disc"
><P
> GIN indexes take about three times longer to build than GiST
</P
></LI
><LI
STYLE="list-style-type: disc"
><P
> GIN indexes are moderately slower to update than GiST indexes, but
about 10 times slower if fast-update support was disabled
(see <A
HREF="gin-implementation.html#GIN-FAST-UPDATE"
>Section 55.3.1</A
> for details)
</P
></LI
><LI
STYLE="list-style-type: disc"
><P
> GIN indexes are two-to-three times larger than GiST indexes
</P
></LI
></UL
><P>
</P
><P
> As a rule of thumb, <ACRONYM
CLASS="ACRONYM"
>GIN</ACRONYM
> indexes are best for static data
because lookups are faster. For dynamic data, GiST indexes are
faster to update. Specifically, <ACRONYM
CLASS="ACRONYM"
>GiST</ACRONYM
> indexes are very
good for dynamic data and fast if the number of unique words (lexemes) is
under 100,000, while <ACRONYM
CLASS="ACRONYM"
>GIN</ACRONYM
> indexes will handle 100,000+
lexemes better but are slower to update.
</P
><P
> Note that <ACRONYM
CLASS="ACRONYM"
>GIN</ACRONYM
> index build time can often be improved
by increasing <A
HREF="runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM"
>maintenance_work_mem</A
>, while
<ACRONYM
CLASS="ACRONYM"
>GiST</ACRONYM
> index build time is not sensitive to that
parameter.
</P
><P
> Partitioning of big collections and the proper use of GiST and GIN 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 search results using the <A
HREF="dblink.html"
>dblink</A
>
module. The latter is possible because ranking functions use
only local information.
</P
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="textsearch-debugging.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="textsearch-psql.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Testing and Debugging Text Search</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="textsearch.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><SPAN
CLASS="APPLICATION"
>psql</SPAN
> Support</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>
Mini Shell