すべてが 1 つの「所有者」テーブルに関連しているテーブル間にいくつかの関係があります。したがって、例のために：
- PK ID を持つテーブル所有者
- Owner.id を参照する PK id と FK owner_id を持つテーブル Parent、その上にインデックス、および
ON DELETE CASCADE. - Parent.id を参照する PK id と FK の parent_id を持つ Table Child と、その上にインデックスがあり、
ON DELETE CASCADE.
Child テーブルは非常に大きく (~5,000 万行)、Parent テーブルには数千行あり、Owner テーブルは非常に小さい (~10 行)。
Owner と Parent に関連するテーブルは他にもいくつかありますが、それらは比較的小さく (数千)、外部キーのインデックスも持っていますON CASCADE DELETE。
すべての削除 (約 1,200 万の子行と 1,000 の親行) をカスケードする所有者行を削除すると、非常に高速 (数秒) になることもありますが、1 時間近くかかることもあります。
これを引き起こしている原因を特定するにはどうすればよいですか? explainここで、1はdelete from child where parent_id in (select id from parent where owner_id = 1)所有者行の 1 つの ID であり (確認のためにさまざまな ID を試しました)、Bitmap Heap Scan -> Bitmap Index Scan および Index Scan を使用していると言っています。ON DELETE CASCADEただし、トリガーがあるときに実際に行われることを模倣しているかどうかはわかりません。これらの大幅な遅延の原因を特定するにはどうすればよいですか? Postgres が (行数のために) 順次スキャンを実行することを好むことがあるのではないでしょうか?
同じ行を挿入するのに 8 分しかかからない (アプリケーション ロジックと数千のトランザクション コミットを含む) ため、単純な削除に時間がかかる理由がわかりません。
Postgres 9.1.6 を使用しています