postgresql 中基于匹配字符串或空间连接的更新是否更快？

Question

我使用 PostGIS 和大约 15 亿行的相当大的数据，我想知道与空间连接 (ST_Intersects) 相比，基于一列与另一列的字符串匹配的更新速度更快？

我的意思是：

UPDATE table_grid AS gd
SET col_grid = col_adm
FROM table_adm de
WHERE ST_Intersects(de.geom, gd.geom);

对：

UPDATE table_grid AS gd
SET col_grid = col_adm
FROM table_adm de
WHERE gd.col_match1 = de.col_match1
AND gd.col_match2 = de.col_match2
AND gd.col_match3 = de.col_match3;

请给出一个查询比另一个查询更快的原因

Answer 1

正如评论所强调的那样，如果没有其他细节，这是一个非常抽象的问题。根据您的之前的帖子，我假设：

1. 您的目标是使两个替代更新在功能上等效：找到相同行的相同匹配项，传输相同的值。
2. 在这两种情况下，您都有足够的索引。
3. 您正在将均匀网格的几何形状与更大的不规则（多）多边形相匹配：

在这种情况下，三字符串匹配通常会（快得多）。您可以从旧线程调整演示并自行查看原因：demo

1. 3 个

   join

   上的

   text

   值清晰、精确且具体 - Postgres 仅根据索引就知道匹配的行。

   Text

   到

   text

   中的比较速度很快，并且不需要

   Index Cond

   阶段。在
Filter
2. 的情况下，索引仅有助于第一阶段，它使用不太精确的边界框交集运算符

   ST_Intersects()

   来缩小匹配候选者的范围，但之后它必须执行相当昂贵的逐顶点交集检查

   &&

   台上的所有候选人。

   Filter

   沿 R 树下降很快，但最终的比较必须执行一些平面/球面几何数学，这总是比仅比较字符串时执行的（散列）相等性检查更昂贵。
在 380 个管理区域和 20k 个网格单元中，3 文本匹配需要

&&

，

50ms

需要

st_intersects()

。我通过使用

300ms

创建 table_grid

 来加速这两个更新 - 这样表的所有页面都有 50% 的空白空间，这样当更新到来时，元组的新版本可以保存在后面旧版本。

虽然在演示中我首先通过基于

fillfactor=50

建立 3 文本匹配来使这些功能等效，但请记住后者是不确定的。正如旧线程中所建立的，在没有额外匹配条件的情况下，只要一个网格单元与多个管理区域相交，Postgres 就会不可预测地匹配它。基于交集的匹配的确定性版本会更慢。