postgres_fdwは、外部サーバに関連付けられた外部テーブルを参照するクエリを最初に実行する際に、外部サーバへの接続を確立します。 この接続は保持され、同じセッションで以降の問い合わせのために再利用されます。 しかし、外部サーバへのアクセスに対して複数のユーザ識別子（ユーザマッピング）が使用される場合には、接続はユーザマッピング毎に確立される事になります。

外部サーバ上のリモートテーブルを参照する際に、まだトランザクションが開始されていなければpostgres_fdwはリモートサーバ上でトランザクションを開始します。 ローカルのトランザクションがコミット、あるいはアボートした時、リモートのトランザクションも同様にコミット、あるいはアボートします。 セーブポイントも同様に管理され、リモート側に関連付けられたセーブポイントが作成されます。

ローカルトランザクションがSERIALIZABLE分離レベルを用いている時、リモートトランザクションもSERIALIZABLE分離レベルを使用します。 それ以外の場合にはREPEATABLE READ分離レベルを使用します。 これは、あるクエリが複数のテーブルスキャンをリモート側で行う際に、確実に全てのスキャンにおいて一貫したスナップショットで結果を取り出すためです。 その結果、別の要求によってリモートサーバ側で競合する更新が発生したとしても、あるトランザクション内の問い合わせはリモートサーバからの一貫したデータを参照する事となります。 ローカルのトランザクションがSERIALIZABLEあるいはREPEATABLE READ分離レベルを用いている場合、この動作は期待通りのものでしょう。 一方、ローカルのトランザクションがREAD COMMITTED分離レベルを使用している場合には、予想外の動作かもしれません。 将来のPostgreSQLリリースではこれらのルールに変更が加えられるかもしれません。

postgres_fdwは今のところ、二相コミットのためのリモートトランザクションの準備をサポートしていないことに注意して下さい。

外部サーバからのデータ転送量を削減するため、postgres_fdwはリモート問い合わせを最適化しようと試みます。 これは問い合わせのWHERE句をリモートサーバに送出する事、およびクエリで必要とされていないカラムを取得しない事により行われます。 問い合わせの誤作動のリスクを下げるため、組み込みあるいは外部サーバのextensionsオプションに列挙されている拡張に属するデータ型、演算子、関数だけを用いたものでない限り、リモートサーバにWHERE句は送出されません。 また、そのようなWHERE句で使われる演算子と関数はIMMUTABLEでなければなりません。 UPDATEあるいはDELETEの問い合わせについては、リモートサーバに送出できないWHERE句がなく、問い合わせにローカルな結合がなく、対象のテーブルにローカルな行レベルのBEFOREあるいはAFTERトリガーや格納された生成列がなく、親ビューからのCHECK OPTION制約がないのであれば、postgres_fdwは問い合わせ全体をリモートサーバに送出することで、問い合わせの実行の最適化を図ります。 UPDATEでは、問い合わせの誤った実行のリスクを低減するため、対象列への代入式では組み込みのデータ型、IMMUTABLE演算子、IMMUTABLE関数のみを使わなければなりません。

同一の外部サーバ上の外部テーブルの間の結合がある場合、postgres_fdwはその結合全体を外部サーバに送出します。 ただし、何らかの理由で各テーブルから個別に行を取得する方が効率的だと思われる場合、あるいは結合に含まれるテーブルの参照が異なるユーザマッピングに従う場合を除きます。 JOIN句を送出するにあたり、WHERE句に関して上で説明したことと同じ注意が払われます。

リモートサーバでの実行のために実際に送出される問い合わせはEXPLAIN VERBOSEを用いて調べる事ができます。

postgres_fdwが開いたリモートセッションでは、search_pathパラメータはpg_catalogにだけ設定されますので、スキーマで修飾しなければ組み込みオブジェクトだけが可視です。 postgres_fdw自身が生成した問い合わせでは、常にそのような修飾を行ないますので、これは問題になりません。 しかし、リモートテーブルのトリガやルールによってリモートサーバ上で実行された関数にとっては問題の原因となり得ます。 例えば、リモートテーブルが実際にはビューであれば、そのビューで使われている関数はすべて制限された検索パスで実行されるでしょう。 期待される検索パス環境を確立できるよう、そのような関数では名前はすべてスキーマ修飾するか、そのような関数にSET search_pathオプション(CREATE FUNCTION参照)を付けることをお薦めします。

postgres_fdwは、同様に様々なパラメータでリモートセッション設定を確立します。

これはsearch_pathほど問題にはならないでしょうが、もし必要になったら関数のSETオプションで処理してください。

上のパラメータのセッションレベルの設定を変更することで、この振舞いを覆すことはお薦めしません。 postgres_fdwが正常に動作しない原因となるでしょう。

postgres_fdwのリモートサーバにはPostgreSQL 8.3以降のバージョンを使用する事ができます。 読み取り専用であれば、8.1以降のバージョンまで可能です。 一方、postgres_fdwはIMMUTABLE属性を持った組み込みの演算子と関数が外部テーブルのWHERE句に含まれる場合、リモート側で実行しても安全であると仮定します。そのため、リモートサーバのリリース後に追加された関数が実行のために送出されるかもしれず、結果として「関数が見つかりません」あるいは類するエラーを発生させる事になります。 この種の問題は問い合わせの書き換えによって対処する事ができます。 例えば、最適化を妨げるため、外部テーブルへの参照をOFFSET 0を付けて副問い合わせに埋め込み、問題のある関数や演算子を副問い合わせの外に配置するなどの方法があります。

これはpostgres_fdwで外部テーブルを作成する例です。 まず、拡張をインストールします。

CREATE EXTENSION postgres_fdw;

次に、CREATE SERVERを使って外部サーバを作成します。 この例では、ホスト192.83.123.89でポート5432を監視しているPostgreSQLサーバに接続します。 接続されるデータベースはリモートサーバ上でforeign_dbという名前です。

CREATE SERVER foreign_server
        FOREIGN DATA WRAPPER postgres_fdw
        OPTIONS (host '192.83.123.89', port '5432', dbname 'foreign_db');

リモートサーバで使われるロールを特定するためにユーザマッピングも必要です。ユーザマッピングはCREATE USER MAPPINGで定義されます。

CREATE USER MAPPING FOR local_user
        SERVER foreign_server
        OPTIONS (user 'foreign_user', password 'password');

これでCREATE FOREIGN TABLEにより外部テーブルが作成できるようになりました。 この例では、リモートサーバのsome_schema.some_tableという名前のテーブルにアクセスします。 対応するローカルの名前はforeign_tableです。

CREATE FOREIGN TABLE foreign_table (
        id integer NOT NULL,
        data text
)
        SERVER foreign_server
        OPTIONS (schema_name 'some_schema', table_name 'some_table');

CREATE FOREIGN TABLEで宣言した列のデータ型やその他の属性は、実際のリモートテーブルと一致していることが必須です。 リモートテーブルでどのような名前なのかを個々の列に対してcolumn_nameオプションで指定しない限り、列名も一致していなければなりません。 多くの場合、外部テーブルの定義を手作業で作成するよりも、IMPORT FOREIGN SCHEMAを使用する方が望ましいです。

花田 茂 <shigeru.hanada@gmail.com>