説明

PREPAREはプリペアド文を作成します。 プリペアド文は、性能を最適化するために利用可能なサーバ側オブジェクトです。 PREPARE文を実行すると、指定された問い合わせの構文解析、書き換えが行われます。 その後、EXECUTE文が発行された際に、プリペアド文は実行計画が作成され、実行されます。 この作業の分割により構文解析作業が繰り返されることを防止でき、さらに、特定のパラメータ値に合わせた実行計画を提供することができます。

プリペアド文はパラメータ、すなわち文が実行される時に代入される値を取ることができます。 プリペアド文を作成する時には$1や$2などを使用して、位置によりパラメータを参照してください。 対応するパラメータのデータ型のリストをオプションで指定することもできます。 パラメータのデータ型の指定がない、または、unknownと宣言されている場合、型はパラメータが最初に参照される文脈より（可能ならば）推測されます。 文の実行時には、EXECUTE文内にこれらのパラメータの実際の値を指定します。 詳細はEXECUTEを参照してください。

プリペアド文は現在のデータベースセッションの期間中にのみ保持されます。 セッションが終了すると、プリペアド文は破棄されます。 そのため、再び利用する場合は、再作成する必要があります。 また、これは、1つのプリペアド文を同時実行中の複数のデータベースクライアントから使用することはできないことを意味します。 ただし、各クライアントが個別にプリペアド文を作成することはできます。 プリペアド文を手作業で削除するには、DEALLOCATEコマンドを使用します。

プリペアド文は潜在的には、単一のセッションで同類の問い合わせを多数実行する場合に、パフォーマンスにおける最大の利益がえられます。 パフォーマンスの違いは、文の書き換えや実行計画が複雑なほど顕著になるでしょう。 例えば、問い合わせに多数のテーブルの結合が含まれている場合や、いくつものルールを適用しなければならない場合などが考えられます。 書き換えおよび実行計画が比較的単純で、実行コストが高い文の場合は、プリペアド文の効果はそれほど現れないでしょう。

パラメータ

注釈

プリペアド文では、提供されたEXECUTEの値に対してそれぞれ再計画するのでなく、一般的な計画を利用することができます。 プリペアド文がパラメータを持たない場合、これは即座に起こります。 パラメータを持つ場合は、5回以上の実行の後で、予測されるコストの平均（計画のオーバーヘッドを含む）が一般的な計画のコスト予測よりも高価である計画が生成されたときに、これが起こります。 ひと度、一般的な計画が選ばれれば、そのプリペアド文が存続する間は、それが利用されます。 多くの重複する値がある列で、稀な値を指定したEXECUTEを実行すると、計画のオーバーヘッドを加えた後でも、一般的な計画よりもずっと安価な独自計画が生成できるため、一般的な計画が決して使われなくなるかもしれません。

一般的な計画では、EXECUTEに提供される各値は、列の個別の値の1つで、列の値は均一に分散していることを仮定します。 例えば、統計情報が列の3つの個別値を記録している場合、一般的な計画では列の同値比較において、処理される行の33%にマッチすると仮定します。 列の統計について、一般的な計画では、一意列の選択性について正確に計算することも許しています。 均一に分散していない列における比較や、存在しない値の指定は、平均的な計画のコストに影響を与えるため、一般的な計画が選択されるかどうか、また一般的な計画がいつ選択されるかにも影響します。

プリペアド文に対してPostgreSQLが使用する問い合わせ計画を検証するためには、EXPLAIN、例えばEXPLAIN EXECUTEを使用してください。 一般的な計画が使用される場合には、$nというパラメータ記号が含まれ、独自計画が使用される場合は提供されたパラメータの値で置換されます。 一般的な計画での行推定は、そのパラメータに対して計算した選択性を反映したものになります。

問い合わせの実行計画や問い合わせの最適化のためにPostgreSQLが収集する統計に関する詳細は、ANALYZEのドキュメントを参照してください。

プリペアド文の主要な利点は、文の解析処理と計画作成処理の繰り返しを防止することですが、PostgreSQLでは、以前にそのプリペアド文を使用してから、文の中で使用されているデータベースオブジェクトが定義（DDL）の変更を受けた時は常に再解析処理と計画再作成処理を強制します。 また、一度使用してからsearch_pathの値が変わった場合も、文は新しいsearch_pathを使用して再解析されます。 （後者の振る舞いはPostgreSQL 9.3の時に追加されました。） これらの規則により、プリペアド文の使用は意味的に同じ問い合わせを繰り返し再投入することとほぼ同じになりますが、特に最善の計画が使用している間に変わらずに残る場合、オブジェクトの変更がない場合の性能という利点があります。 意味的な等価性が完全ではない場合の例は、 文が未修飾名によってテーブルを参照し、その後同じ名前のテーブルが新たにsearch_path内で前に現れるスキーマ内に作成された場合、文の中で使用されるオブジェクトには変更がありませんので、自動再解析は行われません。 しかし他の何らかの変更により強制的に再解析された場合、その後の使用では新しいテーブルが参照されるようになります。

pg_prepared_statementsシステムビューを問い合わせることによりセッションで利用可能なプリペアド文をすべて確認することができます。

例

INSERT文に対してプリペアド文を作成し、実行します。

PREPARE fooplan (int, text, bool, numeric) AS
    INSERT INTO foo VALUES($1, $2, $3, $4);
EXECUTE fooplan(1, 'Hunter Valley', 't', 200.00);

SELECT文に対してプリペアド文を作成し、実行します。

PREPARE usrrptplan (int) AS
    SELECT * FROM users u, logs l WHERE u.usrid=$1 AND u.usrid=l.usrid
    AND l.date = $2;
EXECUTE usrrptplan(1, current_date);

第2パラメータのデータ型が指定されていないことに注目してください。 このため$2が使用される文脈からデータ型が推測されます。

互換性

標準SQLにはPREPARE文が含まれていますが、埋め込みSQLでの使用に限られています。 また、標準SQLのPREPARE文では多少異なる構文が使用されます。

関連項目