Optimization 使用联接（大表性能）Postgresql从更新？

我正在尝试以合理的性能执行以下查询：

UPDATE order_item_imprint SET item_new_id = oi.item_new_id
      FROM order_item oi
      INNER JOIN order_item_imprint oii ON oi.item_number = oii.item_id          

目前，它不能在8天内完成，所以我们杀了它。查询说明如下：

Merge Join  (cost=59038021.60..33137238641.84 rows=1432184234121 width=1392)
Merge Cond: ((oi.item_number)::text = (oii.item_id)::text)
  ->  Nested Loop  (cost=0.00..10995925524.15 rows=309949417305 width=1398)
        ->  Index Scan using unique_order_item_item_number on order_item oi  (cost=0.00..608773.05 rows=258995 width=14)
        ->  Seq Scan on order_item_imprint  (cost=0.00..30486.39 rows=1196739 width=1384)
  ->  Materialize  (cost=184026.24..198985.48 rows=1196739 width=6)
        ->  Sort  (cost=184026.24..187018.09 rows=1196739 width=6)
              Sort Key: oii.item_id
              ->  Seq Scan on order_item_imprint oii  (cost=0.00..30486.39 rows=1196739 width=6)

我在两个表上都有索引，并且我已经确保比较字段的类型和大小相同。我现在正试图改变postgresql服务器的配置，希望能有所帮助，但我不确定它是否会

order_item_imprint表的大小约为110万，占用磁盘空间为145MB，order_item表的大小约为该表的三分之一

主要目标是我需要能够在几个小时的维护时间内运行这个查询和其他几个查询

---

自动抽真空和分析已在执行计划之前运行。

我找到了另一种编写查询的方法，使pgsql优化器能够更高效地构建查询：

UPDATE order_item_imprint SET item_new_id = oi.item_new_id 
FROM order_item oi where oi.item_number = order_item_imprint.item_id

显然，连接是多余的，可以使用以下执行计划：

Hash Join  (cost=1.38..5.73 rows=48 width=1407)
  Hash Cond: ((order_item_imprint.item_id)::text = (oi.item_number)::text)
  ->  Seq Scan on order_item_imprint  (cost=0.00..3.63 rows=63 width=1399)
  ->  Hash  (cost=1.17..1.17 rows=17 width=23)
        ->  Seq Scan on order_item oi  (cost=0.00..1.17 rows=17 width=23)

---

我找到了另一种写这封信的方法 允许使用pgsql优化器的查询 要构建查询，请执行更多操作 有效地

实际上，您所做的是删除order\u item\u inprint上的无约束自联接

如果查看第一行，您将看到以下行估计值：

行数=143184234121

---

这是它试图做的14亿次更新。当您在联接中使用order\u item\u inprint别名时，它被视为与更新目标分离的一个表。

该表上有什么类型的索引？在哪一列？连接的列是什么数据类型？它是什么类型的联接（1:1，1:N）？它们是两列上的B树索引，并且它是1:N联接，正如您在上一个联接中看到的1.xxx万亿行所示。