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

Question

由于散列小于冗长的文本，因此在我看来，它们可能比 b 树更可取，以确保列的唯一性。

仅出于确保唯一性的目的，是否有任何理由在 PG 10 中无法执行以下操作？

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

我假设哈希冲突是在内部处理的。否则将毫无用处。

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

Answer 1

我认为引用手册对此进行了总结：

尽管它是允许的，但使用带有排除约束的 B-tree 或哈希索引没有什么意义，因为这并没有比普通的唯一约束做得更好。所以在实践中访问方法将始终是 GiST 或 SP-GiST。

更何况你还是想创建一个 GiST 索引。排除约束USING GIST将自动创建一个匹配的 GiST 索引作为实现细节。维护另一个甚至没有在查询中使用的低效哈希索引毫无意义。

对于简单的唯一性 ( WITH =)，普通的UNIQUEbtree 索引更有效。如果您的键很长，请考虑在哈希表达式上使用唯一索引（使用任何不可变函数）以减小大小。喜欢：

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

有关的：

• PostgreSQL 如何强制执行 UNIQUE 约束/它使用什么类型的索引？

md5()将是一个简单的选项作为散列函数。

• 将文本表示中的十六进制转换为十进制数
• 当所有值都是 36 个字符时，使用 char 与 varchar 进行索引查找会明显更快吗

在Postgres 10之前，不鼓励使用哈希索引。但是随着最新的更新，这种情况有所改善。Robert Haas（核心开发人员）在一篇博文中总结道：

• PostgreSQL 的哈希索引现在很酷

CREATE INDEX test_path_hash_idx ON test USING HASH (path);

唉（在我的草稿中错过了），访问方法“哈希”还不支持唯一索引。所以我仍然会使用上面哈希表达式的唯一索引。（但没有任何减少信息的散列函数可以完全保证密钥的唯一性——这可能是也可能不是问题。）