带有文本列的多列索引的 Postgres 优化

Question

我有一个关于Postgres中索引优化的问题，我在网上没有找到太多帮助，我一直在努力通过测试自己得到答案。

我有这张桌子

CREATE TABLE "public"."crawls" (
    "id" uuid NOT NULL DEFAULT uuid_generate_v4(),
    "parent_id" uuid,
    "group_id" timestamp,
    "url" varchar(2083) NOT NULL,
    "done" boolean;
    PRIMARY KEY ("id")
);
CREATE UNIQUE INDEX "parentid_groupid_url" ON "public"."urls" USING BTREE ("parent_id","group_id","url");

这是一个 URL 存储，用于计算每个父级和每个组唯一的 URL 的完整列表。我只需要在这个索引上完全匹配。 这意味着只要 group_id 不同，parent_id 就可以多次同时具有相同的 URL。

该表包含数亿个URL，主要用于写入，UNIQUE索引用于去重。

  UPDATE crawls
  SET
    done = TRUE
  WHERE
    url = $1 AND
    parent_id = $2 AND
    group_id = $3

INSERT 

INTO crawls (
      url,
      parent_id,
      group_id
    ) VALUES
      ('long urls', uuid, date)
    ON CONFLICT parentid_groupid_url DO NOTHING

---

目前性能还可以，但可能会更好，并且由于 url 列，索引大小大于表本身。

我想知道如何改进尺寸和/或性能？ （如果可能，两个）

我考虑过使用一个新列对 URL 进行散列 (md5, sha1) 并在索引中使用它而不是 URL，以便长度一致、更小并且对于 Postgres 可能更快，但我没有找到任何帮助。 由于哈希的“随机性”，我不确定它是否有效，并且由于在我的产品上构建索引的大小和时间，我很难测试这个假设。

我在网上找到的参考资料：

• https://www.postgresql.org/docs/12/indexes-types.html
• https://ankane.org/large-text-indexes

谢谢，

Answer 1

我考虑过使用一个新列对 URL 进行哈希 (md5, sha1) 并在索引中使用它而不是 URL，以便长度一致、更小并且对于 Postgres 可能更快

create index on crawls (parent_id,group_id,md5(url));

这将自动强制唯一性（并且还禁止在完整 URL 上真正不同的 md5 冲突 - 但在没有恶意的情况下发生这种情况的可能性很小）。但是，它不会自动用于快速查找，您必须调整查询以允许使用它：

WHERE
  md5(url) = md5($1) AND
  parent_id = $2 AND
  group_id = $3

您可以使用比十六进制更短的表示来节省更多空间：

create index on crawls (parent_id,group_id,decode(md5(url),'hex'));

但这会让它使用起来更加麻烦。

由于哈希的“随机性”，我不确定它是否有效

这完全取决于您的使用模式和数据分布。如果你经常访问一系列具有相同 parent_id 和 group_id 的记录以及相邻的 url，并且具有相同 parent_id 和 group_id 的记录数量很大，那么对 url 进行哈希处理会降低缓存的有效性。

由于在我的产品上构建索引的大小和时间，我很难测试这个假设。

没有测试环境就是双手被绑在背后。