Document not using database hash indexes
This commit is contained in:
parent
6735e1dc9a
commit
a4a8cae7e1
2 changed files with 21 additions and 0 deletions
|
@ -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
|
||||
|
||||
|
|
20
doc/development/hash_indexes.md
Normal file
20
doc/development/hash_indexes.md
Normal 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.
|
Loading…
Reference in a new issue