Commit ebe4375f authored by Bruce Momjian's avatar Bruce Momjian

Document problems with hash indexes compared to btree.

parent db650b45
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/indices.sgml,v 1.31 2002/01/07 02:29:12 petere Exp $ -->
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/indices.sgml,v 1.32 2002/06/21 03:25:53 momjian Exp $ -->
<chapter id="indexes">
<title id="indexes-title">Indexes</title>
......@@ -181,12 +181,9 @@ CREATE INDEX <replaceable>name</replaceable> ON <replaceable>table</replaceable>
</synopsis>
<note>
<para>
Because of the limited utility of hash indexes, a B-tree index
should generally be preferred over a hash index. We do not have
sufficient evidence that hash indexes are actually faster than
B-trees even for <literal>=</literal> comparisons. Moreover,
hash indexes require coarser locks; see <xref
linkend="locking-indexes">.
Testing has shown that hash indexes are slower than btree indexes,
and the size and build time for hash indexes is much worse. For
these reasons, hash index use is discouraged.
</para>
</note>
</para>
......
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_index.sgml,v 1.31 2002/05/18 15:44:47 petere Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_index.sgml,v 1.32 2002/06/21 03:25:53 momjian Exp $
PostgreSQL documentation
-->
......@@ -329,6 +329,11 @@ ERROR: Cannot create index: 'index_name' already exists.
an indexed attribute is involved in a comparison using
the <literal>=</literal> operator.
</para>
<para>
Testing has shown that hash indexes are slower than btree indexes,
and the size and build time for hash indexes is much worse. For
these reasons, hash index use is discouraged.
</para>
<para>
Currently, only the B-tree and gist access methods support multicolumn
......
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/xindex.sgml,v 1.25 2002/05/29 17:36:40 tgl Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/xindex.sgml,v 1.26 2002/06/21 03:25:53 momjian Exp $
PostgreSQL documentation
-->
......@@ -11,9 +11,9 @@ PostgreSQL documentation
<para>
The procedures described thus far let you define new types, new
functions, and new operators. However, we cannot yet define a secondary
index (such as a B-tree, R-tree, or
hash access method) over a new type or its operators.
functions, and new operators. However, we cannot yet define a
secondary index (such as a B-tree, R-tree, or hash access method)
over a new type or its operators.
</para>
<para>
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment