バージョン 9 シリーズからのアップグレードを試みており、10 および 11 では問題なく動作するが、12 および 13 では何倍も遅くなる、契約を破る低速のクエリがあります。11 および 12 シリーズのマイナー バージョンでテストしました。 、マイナー バージョンは影響しません。
問題は、プランナーが使用すべきハッシュ結合ではなく、ネストされたループ結合を選択することにあります。
v11 ハッシュ結合:
-> Nested Loop Left Join (cost=276056.74..285056.52 rows=1714 width=230) (actual time=13519.865..15864.542 rows=57 loops=1)
Join Filter: (placement_type.placement_type_id = job_order.placement_type_id)
Rows Removed by Join Filter: 57
-> Nested Loop Left Join (cost=276056.74..284967.78 rows=1714 width=224) (actual time=13519.837..15864.202 rows=57 loops=1)
-> Hash Join (cost=276056.32..284215.53 rows=1714 width=217) (actual time=13519.803..15863.465 rows=57 loops=1)
Hash Cond: (ori.order_id = job_order_1.order_id)
-> HashAggregate (cost=246953.68..250381.92 rows=342824 width=487) (actual time=13397.503..15017.114 rows=1053462 loops=1)
v12 ネストされたループ:
-> Nested Loop Left Join (cost=304636.78..316645.32 rows=1716 width=230) (actual time=17799.135..152297.231 rows=57 loops=1)
Join Filter: (placement_type.placement_type_id = job_order.placement_type_id)
Rows Removed by Join Filter: 57
-> Nested Loop Left Join (cost=304636.78..316556.50 rows=1716 width=224) (actual time=17799.111..152296.749 rows=57 loops=1)
-> Nested Loop (cost=304636.37..315803.37 rows=1716 width=217) (actual time=17799.075..152295.098 rows=57 loops=1)
Join Filter: (job_order_1.order_id = ori.order_id)
Rows Removed by Join Filter: 60047277
テスト環境でのアップグレード手順は、このクエリをテストする前に pg_upgrade と完全な分析で行われます。
12で何が変わったの?