PostgreSQLのFDW、便利だけど「魔法」じゃないんだよ。性能を引き出すための現場的Tips
現場で「とりあえず外部データを結合して表示したい」という時、PostgreSQLのFDW（Foreign Data Wrapper）は本当に魔法のように便利だよね。`postgres_fdw`を使えば、別のサーバーにあるテーブルがまるで手元にあるかのように扱える。
でもね、これ、「魔法のように見えるのは、裏でPostgreSQLが死ぬほど頑張っているから」なんだ。
今日は、FDWを使っていて「あれ、なんか急に遅くなった？」と悩んだことがある人に向けて、パフォーマンスの裏側と、どうやって最適化していくか、現場の視点で少し深掘りしてみようと思う。
—
FDWの「プッシュダウン」こそが正義だ
まず、FDWのパフォーマンスを語る上で欠かせないのが「プッシュダウン（Pushdown）」という概念。
簡単に言うと、「処理をリモート側に丸投げできるか？」ということ。
もし、リモートサーバーにある100万件のテーブルから、`WHERE id = 123`で1件だけ取り出したいとする。この時、理想的なクエリ計画はこうなるはずだよね。
— 理想的なクエリ（プッシュダウン成功）
SELECT FROM remote_table WHERE id = 123;
— リモート側での実行SQL: SELECT FROM remote_table WHERE id = 123;
これがもしプッシュダウンされないとどうなるか。PostgreSQLは「とりあえず100万件全部持ってきて、手元でフィルタリングする」という、エンジニアとして震えるような動作をする。ネットワーク帯域とメモリをドブに捨てるようなものだ。
プッシュダウンを確認する方法
まずは、自分が書いたクエリがちゃんとプッシュダウンされているか、`EXPLAIN`で確認する癖をつけよう。
EXPLAIN VERBOSE SELECT FROM foreign_table WHERE status = ‘active’;
出力結果の中に `Remote SQL` という項目が出ていれば成功。ここを見れば、実際にリモートサーバーに投げられているクエリが丸見えになる。ここを見て「あ、WHERE句が消えてる…」と気づくのが、脱・初心者の第一歩だね。
—
ネットワーク遅延は「見えないコスト」
FDWを使う上で、もっとも無視できないのが「ネットワーク往復（RTT）」だ。
特にJOINの時が一番危険。リモート側のテーブルとローカルのテーブルをJOINする場合、PostgreSQLは賢いので「リモート結合」を試みることもあるけれど、統計情報が古かったり、複雑な結合条件だったりすると、「まずはリモートから全データ引っ張ってきて、ローカルでJOINする」という計画を立てることがある。
現場での対策：統計情報の更新
FDWのテーブルに対して、`ANALYZE`を忘れていないかな？
— リモート側のテーブル情報をローカルに同期させる
ANALYZE foreign_table;
これだけで、クエリプランナは「あ、このテーブルには100万件あるんだな。じゃあJOINするより、リモート側でフィルタリングしてもらった方が速いな」と判断してくれるようになる。統計情報が古いと、プランナは「たった10行しかない」と勘違いして、非効率な実行計画を選択しがちだ。
—
もっと速くしたい？ それなら「インポート」も視野に入れて
もし、どうしてもネットワーク遅延がボトルネックで、クエリのレスポンスが改善しないなら、発想を切り替える必要がある。
1. マテリアライズド・ビュー（MV）の検討:
リアルタイム性がそこまで重要じゃないなら、定期的にデータをローカルにコピーするMVを作ったほうが、FDWを叩くより圧倒的に速い。
2. `IMPORT FOREIGN SCHEMA`で絞り込む:
必要なカラムだけを定義する。不要な巨大テキストカラムをフェッチするだけで無駄な通信が発生するからね。
3. `updatable`や`use_remote_estimate`の設定:
`CREATE SERVER`や`CREATE FOREIGN TABLE`のオプションを見直そう。特に `use_remote_estimate` を `on` にすると、リモート側の統計情報を毎回見に行くようになる（ネットワークコストは増えるが、プランが最適化されるケースがある）。
—
最後に：先輩からのアドバイス
FDWは「開発スピード」と「実行速度」のトレードオフを、非常にわかりやすく突きつけてくる機能だ。
- SELECTだけならいいけど、JOINや集計が絡むなら要注意。
- 必ず `EXPLAIN` で `Remote SQL` を見る。
- 統計情報は鮮度が命。
「FDWだから遅いのは仕方ない」と諦める前に、まずはクエリがどうリモートに伝わっているのか、その会話を覗いてみてほしい。PostgreSQLは、こちらが意図を正しく伝えてあげれば、驚くほど賢い答えを返してくれるはずだよ。
また何か詰まったら、いつでも聞いてくれ。現場で戦うエンジニアを、俺はいつでも応援しているよ。
コメント