我正在重温 16 年前关于 PostgreSQL HASH 索引与 B-TREE 的一个老问题。当时，HASH 索引在空间和时间方面的效率似乎远低于 B-TREE，并且共识是 HASH 索引在许多用例中没有提供显着的性能优势。
我很好奇2024年情况有变化吗？ 对这个答案（以及链接的文档）的评论表明，对 PostgreSQL 中的 HASH 索引进行了一些优化，使其变得可行。它们重要吗？
主要问题：
关于何时在 Postgres 中使用 HASH 索引而不是 B-TREE，目前的最佳实践是什么？
其他注意事项：
HASH 索引是否有需要注意的特定陷阱，特别是：
原始线程中的一条评论指出，“事实上，使用索引来匹配 99% 的行将非常低效，比 seqscan 慢得多。”这在今天仍然适用吗？或者情况是否随着现代优化而发生了变化？
很想听听您在 2024 年关于 PostgreSQL 中 HASH 索引的经验和建议！
哈希索引发生的一件事是，它们在 PostgreSQL v10 中变得安全可靠。现在，您不必在操作系统崩溃后重建索引。
除此之外，没有什么太大改变。哈希索引仍然比 B 树索引受到更少的喜爱，因此它们通常不会优于 B 树索引。如果你有一列包含许多相同的值，它们必然是低效的，但是在我在 2023 年的实验中我没有发现任何哈希索引优于 B 树索引的实际情况。
我的建议是忘记哈希索引。