Document not using database hash indexes

This commit is contained in:
Yorick Peterse 2017-08-11 14:16:08 +02:00
parent 6735e1dc9a
commit a4a8cae7e1
No known key found for this signature in database
GPG key ID: EDD30D2BEB691AC9
2 changed files with 21 additions and 0 deletions

View file

@ -59,6 +59,7 @@
- [Iterating Tables In Batches](iterating_tables_in_batches.md)
- [Ordering Table Columns](ordering_table_columns.md)
- [Verifying Database Capabilities](verifying_database_capabilities.md)
- [Hash Indexes](hash_indexes.md)
## i18n

View file

@ -0,0 +1,20 @@
# Hash Indexes
Both PostgreSQL and MySQL support hash indexes besides the regular btree
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 offence when it detects the use of a hash
index.
Instead of using hash indexes you should use regular btree indexes.