2

ここで 述べたpostgres_fdwように、インデックスにはアクセスできません。

回避策は、リモート サーバーでビューを作成してから、ローカル サーバーでこのビューの外部テーブル ラッパーを作成することです。

しかし、ビューにパラメーターを渡したい場合はどうすればよいでしょうか? 通常、私はそれを作成function(myparam)しRETURNS TABLE()ます。しかし、どのように呼び出すのpostgres_fdwですか？

この状況を解決するためのアイデアはありますか (dblink必要ない場合は使用しないことをお勧めします)。

例

リモートデータベースで実行する次のようなクエリがあります。

select count(f.id_foo)
from foo f 
where f.date < _my_date

ご覧のとおり、_my_date内部にパラメーターがあります。

だから私は外部テーブルを作成my_remote_server_public.my_remote_server_public_fooし、次のようなローカルデータベースから実行しました:

select count(f.id_foo)
from my_remote_server_public.my_remote_server_public_foo f 
where f.date < _my_date

しかし、これを行うと、インデックスpostgres_fdwにアクセスできないため、2〜3分続きます。foo

リモートデータベースで関数get_foo_by_date(_my_date date)を作成し、ローカルデータベースから呼び出すことを考えましたpostgres_fdwが、それが可能かどうかはわかりません...

アップデート

通常のビューを、内部に一定の日付を持つ外部テーブルとして処理すると仮定しましょう。

このビューは、リモート テーブルから ID のリストを返します。

リストされた行をリモート テーブルから削除し、これらをローカル テーブルにアーカイブしたいと考えています。

次のように呼び出すと：

EXECUTE
'WITH rows_to_delete 
AS (DELETE from my_remote_server_public_foo 
    WHERE id_foo 
    IN 
    (SELECT * FROM my_remote_server_public_view_of_rows_to_delete) RETURNING *) 
INSERT INTO my_local_table 
SELECT * FROM rows_to_delete';

5分間続きます...DELETEクエリはインデックスにアクセスできないため...dblinkここでも関数の呼び出しを使用する必要がありますか? 他の回避策はありますか？

4

1 に答える 1

4

問題はpostgres_fdw「インデックスにアクセスできない」ことではなく、集約関数がリモート サーバーに「プッシュ ダウン」されないことです。

これを行う良い方法はまだありませんが、集約プッシュダウンは PostgreSQL が追加したいもののリストに明確に含まれています。

そのような要件にはdblinkを使用するのが最善の方法です。

PostgreSQL 9.6 では、postgres_fdwに関数をプッシュ ダウンするために悪用できる新機能があります。
関数を含む拡張機能を作成し、ローカル データベースとリモート データベースの両方にインストールする必要があります。次に、この拡張機能をextensions外部サーバーのプロパティに追加できます。関数がIMMUTABLEローカルで呼び出された場合、リモート サーバーにプッシュ ダウンされます。
しかし、それは説明できないほど醜いので、お勧めしません。

「更新」として提起された質問は、問題とは何の関係もなく、別の質問として提起されるべきでした。

ここでの問題は、PostgreSQL 9.5 以下の場合です。

  • 外部テーブル間の結合はリモート側にプッシュされません

  • 更新と削除は行単位で行われるため、削除された行ごとにラウンド トリップが必要です。

どちらも PostgreSQL 9.6 で改善されました (集約はそうではありません)。

于 2016-10-10T12:45:11.180 に答える