mirror of
https://github.com/postgres/postgres.git
synced 2025-07-27 12:41:57 +03:00
Document problems with hash indexes compared to btree.
This commit is contained in:
@ -1,4 +1,4 @@
|
|||||||
<!-- $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">
|
<chapter id="indexes">
|
||||||
<title id="indexes-title">Indexes</title>
|
<title id="indexes-title">Indexes</title>
|
||||||
@ -181,12 +181,9 @@ CREATE INDEX <replaceable>name</replaceable> ON <replaceable>table</replaceable>
|
|||||||
</synopsis>
|
</synopsis>
|
||||||
<note>
|
<note>
|
||||||
<para>
|
<para>
|
||||||
Because of the limited utility of hash indexes, a B-tree index
|
Testing has shown that hash indexes are slower than btree indexes,
|
||||||
should generally be preferred over a hash index. We do not have
|
and the size and build time for hash indexes is much worse. For
|
||||||
sufficient evidence that hash indexes are actually faster than
|
these reasons, hash index use is discouraged.
|
||||||
B-trees even for <literal>=</literal> comparisons. Moreover,
|
|
||||||
hash indexes require coarser locks; see <xref
|
|
||||||
linkend="locking-indexes">.
|
|
||||||
</para>
|
</para>
|
||||||
</note>
|
</note>
|
||||||
</para>
|
</para>
|
||||||
|
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$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
|
PostgreSQL documentation
|
||||||
-->
|
-->
|
||||||
|
|
||||||
@ -329,6 +329,11 @@ ERROR: Cannot create index: 'index_name' already exists.
|
|||||||
an indexed attribute is involved in a comparison using
|
an indexed attribute is involved in a comparison using
|
||||||
the <literal>=</literal> operator.
|
the <literal>=</literal> operator.
|
||||||
</para>
|
</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>
|
<para>
|
||||||
Currently, only the B-tree and gist access methods support multicolumn
|
Currently, only the B-tree and gist access methods support multicolumn
|
||||||
|
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$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
|
PostgreSQL documentation
|
||||||
-->
|
-->
|
||||||
|
|
||||||
@ -11,9 +11,9 @@ PostgreSQL documentation
|
|||||||
|
|
||||||
<para>
|
<para>
|
||||||
The procedures described thus far let you define new types, new
|
The procedures described thus far let you define new types, new
|
||||||
functions, and new operators. However, we cannot yet define a secondary
|
functions, and new operators. However, we cannot yet define a
|
||||||
index (such as a B-tree, R-tree, or
|
secondary index (such as a B-tree, R-tree, or hash access method)
|
||||||
hash access method) over a new type or its operators.
|
over a new type or its operators.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
|
Reference in New Issue
Block a user