Hash 在postgresql 9.3中，外键索引应该使用哈希还是btree？

在postgresql 9.3中，对于整型外键，哪个索引的性能更好

我假设一个散列索引，因为外键比较总是用=

或者，当用于外键上的联接时，btree的比较速度是否与hash一样快

因为在postgresql中，主键使用的是btree，这表明它们也更适合外键。

来自：

注意：哈希索引操作目前未记录，因此哈希 数据库崩溃后，可能需要使用

REINDEX

重新生成索引 如果有不成文的变化。此外，对散列索引的更改也不受限制 在初始复制后通过流式复制或基于文件的复制进行复制 基本备份，因此他们对随后出现的问题给出了错误的答案 使用它们。由于这些原因，目前不鼓励使用散列索引

---

也没有证据表明哈希索引比btree有任何性能优势。

您能解释一下外键是如何在内部创建的吗？当我在创建约束时运行iostat时，磁盘没有写入，但有许多读取。对于单线程PostgreSQL系统，创建外键的过程非常需要I/O（读取）和CPU。

这取决于具体情况

如果您没有使用外键进行任何查询，那么。引用完整性是使用被引用主键的索引强制实现的

因此，对于任何列，使用哪种索引类型（如果有）的问题是相同的。如果您的查询将受益于用于比较的索引，并且您正在使用PostgreSQL10或更高版本，那么哈希索引是一个合理的选择。如果在任何订购操作中涉及相同的列（

orderby

，

=

，等等），那么您也可以使用BTREE

---

如果您非常关心相对性能，那么您需要使用自己的数据分布和查询负载自己测试它们。由于数据访问的局部性（顺序与随机），树索引的性能可能仍然比哈希更好。

非常奇怪。你可能会认为散列索引会快得多，但大量的基准测试表明，它最多只能稍微快一点。对于典型的内存数据结构（例如Java的

HashMap

vs

TreeMap

），哈希比基于树的要快得多。是因为Postgres速度慢，还是仅仅因为Postgres的哈希索引实现没有得到很好的维护？这在postgresql 10+@sudo大树有更好的数据局部性，而哈希表是随机分布的。缓存性能有很大的不同，尤其是在从磁盘读取时。即使在Postgres 10+中，将索引切换到哈希也没有显示出任何改进。我忘了当时的情况。数据位置。。。我不明白为什么这在平等性检查中会有帮助，除非对其中一方进行了排序。