問題タブ [foreign-data-wrapper]

Postgres-9.4 で FDW シナリオをシミュレートするために、両方の postgres-9.4 を使用する単純な 2 つの CentOS サーバー構成があります。

fdw を使用して単純なテーブルを別のサーバー上の別のデータベースにリンクしました。読み取りは両端から完全に機能しました。問題はシリアル主キーにあり、同期していませんでした。つまり、元のテーブルから挿入した場合、外部テーブルから挿入した後、カウントは同期されません。およびその逆。

database_a に外部テーブル ( foo_table) を作成しています。foo_tabledatabase_b に住んでいます。 foo_table列の 1 つとして列挙型 ( bar_type) があります。この列挙型は database_b にあるため、database_a での外部テーブルの作成は失敗します。database_a は列の型を認識していません。database_a で以下を実行

CREATE FOREIGN TABLE foo_table (id integer NOT NULL, bar bar_type) SERVER database_b

エラーが発生します：

ERROR: type "bar_type" does not exist

database_a にのコピーを作成することもできbar_typeますが、これは重複しているように感じられ、将来の不整合の原因になる可能性があります。取り扱いのベストプラクティスについて考えている人はいますか?

2 つの異なる postgres 9.3 インスタンス (1 つは本番用、もう 1 つは開発/テスト用) を実行しています。本番環境のテーブルのサブセットを開発環境にコピーしたいと考えています。

次に、コピーしたいテーブルが次のように定義されているとしましょう

コピーしたいサブセットは、キャッシュされたテーブル (本番環境) に user_id を持つすべてのユーザーです。これは、users テーブルよりもはるかに小さいテーブルです。

これらの2つのテーブル（それぞれforeign_usersとforeign_user_id_subsetという名前）にアクセスするために、開発データベースにいくつかの外部テーブルを設定しました。次のようなクエリを実行したいと思います。

このクエリは機能しますが、パフォーマンスが心配です。Explain の結果は次のようになります。

私が考えているのは、開発データベースが本番データベースにリクエストを送信し、それがforeign_user_id_subset（本番環境ではuser_id_subset）の一時ハッシュを作成し、本番環境でハッシュチェックを行うことです。このように、(データベース間で) ネットワークを介して送信されるのは、最初の要求と、選択クエリの結果だけです。これは本当ですか？

別のアイデアは、本番データベースでこのリクエストの結果の「一時」（真の TEMP テーブルにすることはできません。外部テーブルが必要です）を作成し、次に外部テーブルを構築して、 SELECT * 外部テーブルの開発から。

(私の本番データベースは、私の開発データベースよりもはるかに高価でパフォーマンスの高い RDS インスタンスであることに注意してください)

したがって、外部テーブルに挿入したいレコードが多数ある場合は、次のようにすることができます (疑似コード):

またはこれ：

私の直感では、SQL キーワードの繰り返しが少なく、すべてのデータが一度に送信されるため、2 番目の方が効率的です。

ただし、2 番目の結果が実際に往復回数と同じになるかどうかはわかりません。また、行数が多い場合、2番目が何らかのステートメントの長さの制限に達するリスクがあるかどうかもわかりませんか?

私はpostgres 9.3を使用しています

リモート スキーマ:

ローカル スキーマ:

ローカルでINSERTon を実行するとsome_table_view_fdw、relation not found: some_table.

• some_table_view_fdw から問題なく選択できます (some_table_view は * from を返すだけですsome_table)。
• insert into some_table_view は、ローカル (リモート) で実行すると問題なく動作します。トリガーは、本来あるべきことを行います。
• some_table_view_fdw は some_table を直接参照しないことに注意してください。したがって、トリガーが実行されている必要があると思いますが、何らかの理由でそれ自体のテーブルが見つかりませんか?

私はpostgres 9.3を使用しています