-
+
Indexes
- 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.
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
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.