PostgreSQL HASH索引

Question

PostgreSQL HASH索引

Nic*_*ard 28 sql database postgresql indexing

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

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

谢谢
:MySQL的HASH怎么样？

Answer 1

Ken*_*ric 34

在具有已知键值的情况下,哈希比B树快,尤其是已知的唯一值.

如果有问题的列被散列应该使用从来旨在与相对扫描<或>命令.

哈希是O(1)复杂的,B树是O(log n)复杂的(iirc),因为对于具有唯一条目的大型表,获取ITEM="foo"它们,它们将是查找它的最有效方式.

这尤其是当这些独特的领域是在连接条件使用实用.

应该注意的是,从版本8.4开始,Hash索引的效率低于b树索引的问题得到解决.http://www.postgresql.org/docs/8.4/static/release-8-4.html#AEN95616 (10认同)
只有一个问题,据我所知,二叉树搜索是O(logn),而不是O(n*logn),我是对的吗？ (5认同)
实际上,在调查PostgreSQL开发人员的观点之前,这几乎就是我的想法.但似乎即使对于你所描述的情况,HASH在效率和效率方面也没有超过B-TREE,因为理论算法似乎并不那么实用.谢谢 (3认同)

Answer 2

Cli*_*son 6

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

对于像URL这样的东西,哈希索引大约是B-Tree索引大小的30%.

缩小的大小允许PostgreSQL更有效地使用它的缓存(Aka,shared_buffers).

Answer 3

Die*_*oza 5

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

从 v10 开始，这不再是正确的。https://www.enterprisedb.com/blog/postgresqls-hash-indexes-are-now-cool (2认同)

归档时间：	16 年，10 月前
查看次数：	8911 次
最近记录：	9 年，10 月前