ユニーク制約がPostgres DBの書き込みパフォーマンスに与える影響

Question

カラムまたはカラムグループに指定されたUNIQUE制約は、Postgres DBの書き込みパフォーマンスに何らかの影響を及ぼしますか？内部でどのように機能していますか？

つまり、新しいレコードの挿入時にユニークなチェックを実行しますか？はいの場合、それはどうしますか？DBに既に存在する重複値を線形検索しますか？その場合、パフォーマンスに影響を及ぼすとみなされます。つまり、固有の制約の数が増えると、書き込み/挿入のパフォーマンスが低下します。本当ですか？

Answer 1

UNIQUE制約またはPRIMARY KEYを作成すると、UNIQUE btreeインデックスが作成されます。このインデックスは、レコードがINSERT ed、UPDATE ed、またはDELETE dの場合はいつでも更新する必要があります。の場合は、インデックスの列が変更されます。インデックス付きの列が変更されていない場合は、特にHOT（ヒープのみのタプル最適化）がインデックスに更新されないようにすることができます。特にページ内にスペースを空けるためにデフォルト以外のFILLFACTORがある場合。

挿入/更新時のインデックス更新に時間がかかるため、UNIQUEインデックス付きテーブルに挿入すると、一意のインデックスまたはプライマリキーを使用しないで挿入するよりも処理が遅くなります。 UPDATEについても同じことが当てはまりますが、更新するタプルを見つけるためにインデックスを使用すると（通常はseqscanを避ける）、通常はインデックスを持たない場合と比較して純粋な勝ちです。タプルの検索に別のインデックスを使用した場合や、seqscanの方が速い場合（小さいテーブルでも同様）、INSERTのようにインデックスには効果がなく、その操作で更新するための書き込みコストがかかります。これは、UNIQUEインデックスだけでなく、すべてのインデックスに当てはまります。

UNIQUEインデックスカラムの各INSERTまたはUPDATEには、キーが既存のキーと競合しないことを確認するためにインデックスルックアップが必要です。あいまいな記憶から、これは新しいエントリをインデックスに挿入するプロセスと組み合わされますが、私は100％確信していません。

AFAIK DELETEインデックスには影響しません。ヒープ内のタプルに対してxmaxを設定するだけです。

ROLLBACKUNIQUE制約付き列で正常に挿入または更新された後、トランザクションまたはトランザクションがエラーで中止されても、インデックスが更新されます。 VACUUM autovacuumによる作業は、後でデッドインデックスエントリを消去します。 Concurrency Control in the PostgreSQL manualを参照してください。

PRIMARY KEYの場合も同様で、UNIQUEインデックスを使用して実装されています。

PRIMARY KEYおよびUNIQUE制約で使用されるインデックスを含むすべてのインデックスは、書き込みパフォーマンスにペナルティが発生します。