我正在尝试以合理的性能执行以下查询:
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表的大小约为3。
主要目标是我需要能够在几个小时的维护时段内与其他几个查询一起运行。
自动真空和分析已在执行计划之前运行。
答案 0 :(得分:7)
我找到了另一种写作的方法 允许pgsql优化器的查询 更多地构建查询 有效地
实际上,你所做的是删除order_item_inprint上的无约束自连接。
如果你看第一行,你会看到以下行估计:
行= 1432184234121
它正试图做14亿次更新。当您在联接中将order_item_inprint别名时,它会被视为更新目标中的单独表。
答案 1 :(得分:4)
我找到了另一种编写查询的方法,允许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)