PREPARE plan_name [ (datatype [, ...] ) ] AS query
PREPARE コマンドでプリペアードクエリを作成します。 プリペアードクエリは、パフォーマンスの最適化に利用できるサーバ側オブジェクトです。 PREPARE 文を実行すると、指定された問い合わせが構文解析され、書き換えられ、そして計画されます。 その後に EXECUTE 文が発行されると、プリペアードクエリは実行されるのみです。 このようにすると、構文解析、書き換え、そして計画は一度だけ行えば良く、問い合わせが実行される度に行う必要がなくなります。
プリペアードクエリはパラメータ、すなわち問い合わせが実行されるときに代入される値を取ります。 プリペアードクエリにパラメータを指定するには、PREPARE 文にデータ型のリストを含めます。 問い合わせ自体では、$1、$2 などを使用した位置によってパラメータを参照します。問い合わせの実行時には、EXECUTE 文内にこれらのパラメータの実際の値を指定します。詳細については EXECUTE を参照してください。
プリペアードクエリは、ローカル (現行のバックエンド) に格納され、現行のデータベースセッションの間のみ存在します。クライアントが終了する際に、プリペアードクエリも忘れ去られてしまうので、再度使用される前に再作成する必要があります。つまり、単一のプリペアードクエリを複数のデータベースクライアントで同時に使用することはできないということです。しかし、それぞれのクライアントが各自のプリペアードクエリを作成することができます。
プリペアードクエリの利点を最大限に発揮できるのは、単一のバックエンドで多数の同類の問い合わせを実行する場合です。 パフォーマンスの違いは、問い合わせの計画や書き換えが複雑なほど顕著になるでしょう。 例えば、問い合わせで多数のテーブルが結合されている場合、あるいはいくつものルールを適用しなければならない場合などです。 問い合わせの計画および書き換えは比較的単純だが実行のコストが比較的高いという場合には、プリペアードクエリの利点はさほど目立たないでしょう。
状況によっては、プリペアードクエリとして PostgreSQL が生成した問い合わせ計画は、普通に送信され実行された場合の計画よりも劣ってしまう場合があります。 これは、問い合わせを計画する際 (オプティマイザが最適な問い合わせ計画を判断する際)、問い合わせ内でパラメータに指定された実際の値を使用できないことが原因です。 PostgreSQL はテーブル内の配布データに関する統計を集め、そして定数を使用することで問い合わせの実行結果を予測することができます。 パラメータを持つプリペアードクエリを計画する際にこのデータを使用できないため、選択される計画は最適ではない可能性があります。
問い合わせの計画、および問い合わせの最適化のために PostgreSQL が収集する統計に関する詳細は ANALYZE の文書を参照してください。