PostgreSQL 可以使用 HASH 排除约束来实现唯一性吗？

Question

由于哈希值比长文本小，因此在我看来，它们可能比 B 树更好，以确保列的唯一性。

仅出于确保唯一性的目的，是否有任何原因导致以下内容在 PG 10 中不正常？

CREATE TABLE test (
  path ltree,
  EXCLUDE USING HASH ((path::text) WITH =)
);

我假设哈希冲突是在内部处理的。否则就没用了。

我将使用 GiST 索引来增强查询。

Answer 1

我认为quoting the manual对此总结如下:

Although it's allowed, there is little point in using B-tree or hash indexes with an exclusion constraint, because this does nothing that an ordinary unique constraint doesn't do better. So in practice the access method will always be GiST or SP-GiST.

既然您无论如何都想创建一个 GiST 索引，那就更是如此。使用 USING GIST 的排除约束将自动创建一个匹配的 GiST 索引作为实现细节。维护另一个甚至不在查询中使用的低效哈希索引毫无意义。

对于简单的唯一性 (WITH =)，普通的 UNIQUE btree 索引更加高效。如果您的键很长，请考虑在哈希上使用唯一索引 expression (使用任何不可变函数)来减小大小。喜欢:

CREATE UNIQUE INDEX test_path_hash_uni_idx ON test (my_hash_func(path));

相关:

• How does PostgreSQL enforce the UNIQUE constraint / what type of index does it use?

md5() 将是一个简单的哈希函数选项。

• Convert hex in text representation to decimal number
• Would index lookup be noticeably faster with char vs varchar when all values are 36 chars

在Postgres 10之前，不鼓励使用哈希索引。但是with the latest updates ，这已经有所改善。 Robert Haas(核心开发人员)在博客文章中总结道:

• PostgreSQL's Hash Indexes Are Now Cool

CREATE INDEX test_path_hash_idx ON test USING HASH (path);

唉(在我的草稿中遗漏了这一点)，访问方法“hash”还不支持唯一索引。所以我仍然会使用上面的哈希表达式的唯一索引。 (但是没有任何减少信息的哈希函数可以完全保证 key 的唯一性 - 这可能是问题，也可能不是问题。)