summaryrefslogtreecommitdiff
path: root/doc/development/database/hash_indexes.md
diff options
context:
space:
mode:
Diffstat (limited to 'doc/development/database/hash_indexes.md')
-rw-r--r--doc/development/database/hash_indexes.md26
1 files changed, 26 insertions, 0 deletions
diff --git a/doc/development/database/hash_indexes.md b/doc/development/database/hash_indexes.md
new file mode 100644
index 00000000000..731639b6f06
--- /dev/null
+++ b/doc/development/database/hash_indexes.md
@@ -0,0 +1,26 @@
+---
+stage: Data Stores
+group: Database
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
+---
+
+# Hash Indexes
+
+PostgreSQL supports hash indexes besides the regular B-tree
+indexes. Hash indexes however are to be avoided at all costs. While they may
+_sometimes_ provide better performance the cost of rehashing can be very high.
+More importantly: at least until PostgreSQL 10.0 hash indexes are not
+WAL-logged, meaning they are not replicated to any replicas. From the PostgreSQL
+documentation:
+
+> Hash index operations are not presently WAL-logged, so hash indexes might need
+> to be rebuilt with REINDEX after a database crash if there were unwritten
+> changes. Also, changes to hash indexes are not replicated over streaming or
+> file-based replication after the initial base backup, so they give wrong
+> answers to queries that subsequently use them. For these reasons, hash index
+> use is presently discouraged.
+
+RuboCop is configured to register an offense when it detects the use of a hash
+index.
+
+Instead of using hash indexes you should use regular B-tree indexes.