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).
This commit is contained in:
Tom Lane 2007-11-16 03:23:07 +00:00
parent f639df0d61
commit fb8b38e4bf
2 changed files with 22 additions and 4 deletions

View File

@ -1,4 +1,4 @@
<!-- $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

View File

@ -1,4 +1,4 @@
<!-- $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.