News for hackers. Stuff that matters.

A comment on Hash indexes are faster than btree indexes?. Parent comment

Re:Hash indexes are faster than btree indexes? by ivoras on Monday March 20, 2017 @08:32AM (#13913519)
Durable in the ACID sense, or specifically that write operations go through the WAL (write-ahead log, i.e. a journal), with all the consequences this brings (both durability and replication).

Before this work was done, hash indexes could literally be corrupted by power outages, etc.

[ Parent | on HN ]
Re:Hash indexes are faster than btree indexes? by almost on Monday March 20, 2017 @08:34AM (#13913541)
Oh right, that's scary! In the case of corruption would the index just be rebuilt (I realise that's a big problem with big indexes) or would it just silently corrupt query output?
[ Parent | on HN ]
Re:Hash indexes are faster than btree indexes? by fabian2k on Monday March 20, 2017 @08:46AM (#13913610)
Caution

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.

That is the warning in the current version of Postgres about hash indexes.

[ Parent | on HN ]