2つの大きなテーブルを結合していて、行を除外できる条件がないため、効率的な結合戦略はハッシュ結合のみであり、インデックスはそれを支援できません。
最初に、ハッシュ構造が構築されるテーブルの1つが順次スキャンされ、次に他のテーブルが順次スキャンされ、見つかった行ごとにハッシュがプローブされます。インデックスはそれをどのように助けますか？
このような操作には長い時間がかかることが予想されますが、操作を高速化する方法がいくつかあります。
-
tx_input1のすべてのインデックスと制約を削除します あなたが始める前に。クエリは、インデックスがまったく役に立たない例の1つですが、実際には痛い インデックスはテーブルと一緒に更新する必要があるため、パフォーマンス。UPDATEの実行が完了したら、インデックスと制約を再作成します。 。テーブル上のインデックスの数に応じて、まともなパフォーマンスから大幅なパフォーマンスの向上が期待できます。 -
work_memを増やしますSETを使用したこの1つの操作のパラメーター できるだけ高いコマンド。ハッシュ操作で使用できるメモリが多いほど、高速になります。テーブルがこれほど大きい場合でも、一時ファイルが存在する可能性がありますが、それでも十分なパフォーマンスの向上が期待できます。 -
checkpoint_segmentsを増やします （またはmax_wal_sizeバージョン9.6以降）から高い値に変更して、UPDATE中のチェックポイントを減らします。 操作。 -
PostgreSQLが作成するハッシュバケットの数を適切に見積もることができるように、両方のテーブルのテーブル統計が正確であることを確認してください。
UPDATEの後 、多数の行に影響する場合は、VACUUM (FULL)の実行を検討してください。 tx_input1で 結果として生じるテーブルの肥大化を取り除くために。これにより、テーブルが長時間ロックされるため、メンテナンス期間中にロックしてください。テーブルのサイズが小さくなり、その結果、順次スキャンが高速化されます。