★PostgreSQLカンファレンス2024 12月6日開催/チケット販売中★
他のバージョンの文書 16 | 15 | 14 | 13 | 12 | 11 | 10 | 9.6 | 9.5 | 9.4 | 9.3 | 9.2 | 9.1 | 9.0 | 8.4 | 8.3 | 8.2 | 8.1 | 8.0 | 7.4 | 7.3 | 7.2

9.25. トリガ関数

現在、PostgreSQLは、1つの組み込みトリガ関数suppress_redundant_updates_triggerを提供しており、通常の動作、つまりデータが変更されようがされまいがに関わらず常に更新をする場合とは正反対に、行のデータを実際に変更しない更新が起こらないようにします。(この通常の動作は、検査を必要としないため更新をより迅速に行い、場合によっては便利です。)

理想的には、通常実際レコード内のデータを変更しない更新の実行を避けるべきです。 冗長な更新により、特に変更対象の多くのインデックスが存在する場合、無視できない不要な時間にかかるコストが発生することがあります。 また、最後にはバキュームしなければならなくなる不要行が場所を取ることになります。 しかし、こうした状況をクライアント側で判定することは常に簡単ではありません。 また、可能であったとしても、それを検知するための式の記述はエラーを招きがちです。 他の方法として、suppress_redundant_updates_triggerを使用することがあります。 これはデータを変更しない更新を飛ばします。 しかしこの関数は注意して使用しなければなりません。 このトリガはレコードごとに小さな、しかし僅かではない時間がかかります。 このため、更新が影響するレコードのほとんどが実際には変更されない場合、このトリガは確実に更新の実行を低速にします。

suppress_redundant_updates_trigger関数は以下のようにテーブルに追加できます。

CREATE TRIGGER z_min_update 
BEFORE UPDATE ON tablename
FOR EACH ROW EXECUTE PROCEDURE suppress_redundant_updates_trigger();

ほとんどの場合、それぞれの行に対しこのトリガを最後に起動させる必要が生じます。トリガは名前順に起動されることを判っているとして、テーブル上に存在する可能性のある他のトリガの名前の後に続くようトリガ名を選択できます。

トリガ作成についてより詳細はCREATE TRIGGERを参照ください。