Document problems with hash indexes compared to btree.
authorBruce Momjian
Fri, 21 Jun 2002 03:25:53 +0000 (03:25 +0000)
committerBruce Momjian
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 @@
-
+
 
 
  Indexes
@@ -181,12 +181,9 @@ CREATE INDEX name ON table
 
    
     
-     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 = comparisons.  Moreover,
-     hash indexes require coarser locks; see 
-     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.
     
      
   
index a3af001006a58fca443f229733faa96bad13262b..6bb972e988e98f3c74d6e550a2f613db8b0161cc 100644 (file)
@@ -1,5 +1,5 @@
 
 
@@ -329,6 +329,11 @@ ERROR: Cannot create index: 'index_name' already exists.
     an indexed attribute is involved in a comparison using
     the = operator.
    
+   
+     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.
+   
 
    
     Currently, only the B-tree and gist access methods support multicolumn
index c6bfb0e19f37495617d005873dab4d31ed522cca..99f069a674893a4488a72e591126de9a7e2e6156 100644 (file)
@@ -1,5 +1,5 @@
 
 
@@ -11,9 +11,9 @@ PostgreSQL documentation
 
   
    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.