PostgreSQL HASH索引

Question

有人知道应该使用PostgreSQL HASH而不是B-TREE的情况，因为在我看来这些东西都是陷阱。它们比B-TREE花费更多的时间来创建或维护（至少10倍），它们也占用更多空间（对于我的一个table.columns，B-TREE占用240 MB，而HASH会占用拿4 GB）我似乎从谷歌搜索中了解到，他们选择的速度不比B-TREE快;然而HASH最近可能已经优化或谷歌错了。

无论如何，我想要你的家伙的意见和经验。如果这些HASH是邪恶的，人们应该知道。

感谢
另外：MySQL的HASH怎么样？

Answer 1

对于具有已知键值的情况，特别是已知的唯一值，哈希比B树快。

如果相关列从不打算使用<或>命令进行相对扫描，则应使用哈希。

哈希值为O(1)复杂度，B树为O(log n)复杂度（iirc），ergo，对于具有唯一条目的大型表，提取ITEM="foo"，它们将是最有效的方式查找它。

当在连接条件下使用这些唯一字段时，这是特别实用。

Answer 2

对于仅使用=运算符搜索的文本列，使用哈希索引会更好。例如，需要为查找编制索引的URL列。

哈希索引大约是URL的B-Tree索引大小的30％。

缩小的大小允许PostgreSQL更有效地使用它的缓存（Aka，shared_buffers）。

Answer 3

由于http://www.postgresql.org/docs/9.2/static/sql-createindex.html点哈希索引仍然不是WAL安全的;这意味着它们对于崩溃不是100％可靠（必须重建索引并且在复制时可能发生错误的响应）。另请查看http://www.postgresql.org/docs/9.1/static/wal-intro.html

Answer 4

我还没试过这个，但我正在考虑这种方法，在未记录的临时表上使用哈希索引。

我的理解是他们建造得更快，占用更少的空间和查询比b-tree略快。

根据this benchmark，哈希索引比BTree索引稍微快一些。但是，您无法使用它们创建唯一的哈希索引 - 此外它们不会被WAL记录。