]> granicus.if.org Git - postgresql/commitdiff
Document problems with hash indexes compared to btree.
authorBruce Momjian <bruce@momjian.us>
Fri, 21 Jun 2002 03:25:53 +0000 (03:25 +0000)
committerBruce Momjian <bruce@momjian.us>
Fri, 21 Jun 2002 03:25:53 +0000 (03:25 +0000)
doc/src/sgml/indices.sgml
doc/src/sgml/ref/create_index.sgml
doc/src/sgml/xindex.sgml

index 417a50dcb35518568ec57b073d4b90f045f0fe47..6317e4ea7499c267bf80e3660e703b4f2dcf0068 100644 (file)
@@ -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">
  <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>
index a3af001006a58fca443f229733faa96bad13262b..6bb972e988e98f3c74d6e550a2f613db8b0161cc 100644 (file)
@@ -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
 -->
 
@@ -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
index c6bfb0e19f37495617d005873dab4d31ed522cca..99f069a674893a4488a72e591126de9a7e2e6156 100644 (file)
@@ -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
 -->
 
@@ -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>