【发布时间】:2021-10-13 03:49:35
【问题描述】:
我有两张大桌子,我需要把它们放在一起。匹配不应该是一个明确的比较。我使用了三元组,Levenshtein 的公式,但我的表现很差。也许有人可以帮助提高性能。 A表大小约20万行,B表大小约60万行。
CREATE TABLE TBL_A(NAME VARCHR,SURNAME VARCHAR, BIRTH_DATE DATE, TABLE_B_ID INT4);
CREATE TABLE TBL_B(ID INT4, NAME VARCHR, SURNAME VARCHAR, BIRTH_DATE DATE);
--variant 1
SET pg_trgm.similarity_threshold = 0.8;
UPDATE TBL_A A SET TABLE_B_ID = B.ID
FROM TBL_B B
WHERE A.NAME % B.NAME
AND A.SURNAME % B.SURNAME
AND ABS(A.BIRTH_DATE ::DATE - B.BIRTH_DATE ::DATE)<=1
--variant 2
UPDATE TBL_A A SET TABLE_B_ID = B.ID
FROM TBL_B B
WHERE A.NAME = B.NAME
AND A.SURNAME = B.SURNAME
AND ABS(A.BIRTH_DATE ::DATE - B.BIRTH_DATE ::DATE)<=1
--variant 3
UPDATE TBL_A A SET TABLE_B_ID = B.ID
FROM TBL_B B
WHERE levenshtein_less_equal (A.NAME ,B.NAME,2)<=2
AND levenshtein_less_equal (A.SURNAME ,B.SURNAME,2)<=2
AND ABS(A.BIRTH_DATE ::DATE - B.BIRTH_DATE ::DATE)<=1
所有这些选项的性能都很差(大约 7 小时)。我尝试创建索引,但速度并没有提高
CREATE INDEX ind_a_name ON TBL_A USING gist(NAME trm_gist_ops);
CREATE INDEX ind_a_Surname ON TBL_A USING gist(SURNAME trm_gist_ops);
【问题讨论】:
-
这看起来是一次性的。就算真的花了7个小时,既然已经完成了,为什么还要重新运行呢?
-
我希望 gin_trgm_ops 在这里比第一个变体的 gist_trgm_ops 快得多。
-
这将是不同对表的常规过程
-
我应该在两个表上创建 gin 索引吗?
-
这两者都应该给你一个提升,但我认为在 TBL_B 上使用它似乎比在 TBL_A 上使用它更自然。
标签: postgresql query-optimization levenshtein-distance metaphone