为什么是postgresql；“不尊重”；散列索引？

我知道postgresql不鼓励使用散列索引。他们实际上说：

注意：哈希索引操作目前未被记录，因此哈希 数据库崩溃后，可能需要使用REINDEX重建索引。 它们也不会通过流式或基于文件的复制进行复制。 由于这些原因，目前不鼓励使用散列索引。”

这是一个完全不使用它们的好理由，但我不明白为什么postgresql开发人员不努力使哈希索引成为一流的公民，并鼓励在某些情况下使用它们，而不是阻止这样做

---

实际上，如果您只需要搜索相等，哈希索引应该远远优于任何类型的树，因为它们在o（1）中进行搜索、插入和删除，而平衡树自然不会比o（log（n））更好。在最坏的情况下，散列索引可以用于o（n），但有一系列已知的技术可以避免最坏的情况。如果我是一个db引擎架构师，那么这样一个论点肯定会决定我是否将哈希索引作为一个可行的替代方案，但对于postgresql，这似乎有所不同。是否有技术上的原因，或者这样的决定不是出于技术上的动机？

树索引，通过使用例如B+树及其变体，非常有效，以至于它们被认为具有O（c）的成本，其中c，树的高度，是一个小常数（c=3或4，可以索引数百万条记录），通常至少会缓存一到两级这样的树，因此在大多数情况下，磁盘访问的数量可以等于1或2

---

因此，出于实际目的，它们的性能类似于散列索引，而且具有允许范围搜索的巨大优势。

但插入和删除的速度是否与B+树的选择速度一样快？在大多数情况下，只要选择好设计参数，您可以通过一次读取和一次写入操作插入和删除元素。只有在（非常罕见的）最坏的情况下，操作需要的写入次数等于树的高度。b树索引与哈希索引一样快。你可以自己试试。