我试图让以下查询以合理的性能执行:
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 优化器的查询
进一步构建查询
有效率的
实际上,您所做的就是删除 order_item_inprint 上的无约束自连接。
如果您查看第一行,您将看到以下行估计:
行=1432184234121
它正在尝试进行 14 亿次更新。当您在联接中为 order_item_inprint 添加别名时,它会被视为与更新目标不同的单独表。
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)