【テクニカル・上級編】外部テーブルに対するインデックス – PostgreSQL

外部テーブルにインデックスが張れないと嘆く前に：PostgreSQLのFDWと「遠隔地」の最適化

PostgreSQLの `postgres_fdw` は、もはや単なる「おまけ」機能ではありません。マイクロサービス間のデータ結合や、分析基盤へのレイク連携など、現代のアーキテクチャでは避けて通れない存在です。

しかし、現場でよく耳にするのが「外部テーブルが遅い。インデックスが張れないから設計が詰んだ」という嘆きです。今日は、この「外部テーブルにはインデックスが作れない」という制約と、どう向き合い、どう設計すべきか。熟練エンジニアの視点で、その裏側にあるアーキテクチャの話をしようと思います。

なぜ「外部」にはインデックスが作れないのか

まず、根本的な事実を確認しましょう。外部テーブルは、PostgreSQLから見れば「テーブルという名のビュー」に近い存在です。実体は外部サーバーのストレージ上にあり、クエリが投げられるたびに FDW（Foreign Data Wrapper）がネットワーク経由でリモートへ命令を飛ばし、結果を受け取ります。

ここにインデックスを作成できないのは、PostgreSQLのローカルカタログ（`pg_class`や`pg_index`）が、外部の実体に対して物理的なファイル配置権限も、ページ管理権限も持っていないからです。ローカルにB-Treeインデックスを作ったとしても、リモートのデータが更新された瞬間、整合性は即座に破綻します。

つまり、「インデックスが張れない」のではなく「ローカルが管理するインデックスとリモートの実体が分離している」というのが本質です。

「リモートのインデックス」がローカルのクエリを変える

ここで多くのエンジニアが陥る罠があります。それは、リモート側にあるテーブルのインデックスを軽視することです。

外部テーブルに対してクエリを実行する際、`postgres_fdw` は極力、WHERE句やJOIN条件をリモート側にプッシュダウンしようとします。ここで重要になるのが、「リモート側でインデックスが効いているか」という一点です。

もし、リモート側のテーブルに適切なインデックスがない場合、FDWは「リモート側でフルスキャン」を実行し、その膨大なデータをネットワーク経由でローカルへ引きずり出します。ローカルでいくら実行計画をチューニングしても、リモート側でシーケンシャルスキャンが走っていれば、すべては水の泡です。

ここが腕の見せ所です：
1. `EXPLAIN VERBOSE` を信じるな、`EXPLAIN (ANALYZE, BUFFERS)` を見ろ： 外部テーブルに対するクエリで、`Remote SQL` という行が出てくるはずです。そこに投げられているSQLを確認してください。
2. プッシュダウンが効いているか： リモートに投げられているSQLにWHERE句が含まれているか。もし含まれていなければ、リモート側はフルスキャンしています。
3. リモートのインデックス設計： 外部テーブルを意識して、リモート側のテーブルに「結合条件（JOIN Key）」や「絞り込み条件（WHERE Key）」に対するインデックスを、ローカルのクエリプランナを意識して作成してください。

隠れたボトルネック：統計情報の乖離

もう一つ、熟練者でも見落としがちなのが「統計情報」です。外部テーブルの統計情報は自動更新されません。`ANALYZE foreign_table_name` を実行しない限り、ローカルのプランナは「このテーブルは100行しかない」と勘違いし、Nested Loopを選択して爆死することがあります。

特に、リモート側でデータが激しく更新される場合、定期的に統計情報を更新するジョブを組むことは、チューニングの第一歩です。

アーキテクチャの視点：本当に「外部テーブル」であるべきか

最後にもう一歩踏み込んだ話をしましょう。

もし、リモートのテーブルに対して頻繁なJOINや複雑な絞り込みが必要であり、かつネットワークのレイテンシが無視できないレベルでパフォーマンスを阻害しているなら、それは「外部テーブルの設計」の問題ではなく、「アーキテクチャの妥協点」の問題かもしれません。

マテリアライズドビューの検討： 頻繁に参照するなら、一定間隔でローカルへデータを同期するマテリアライズドビューの方が、はるかにインデックスの恩恵を受けられます。
データローカリティの原則： 処理の重いJOINは、できる限り同じインスタンス内で完結させる。これがデータベース設計の不変の原則です。

まとめ

外部テーブルは強力な武器ですが、ローカルのインデックスという「魔法」が使えない分、設計者の意図がよりシビアにパフォーマンスへ反映されます。

「インデックスが張れない」と嘆く前に、リモート側のプランナと対話してください。リモートに適切なインデックスを配置し、統計情報を最新に保ち、ネットワークを流れるデータ量を最小化する。

こうした泥臭い最適化の積み重ねこそが、PostgreSQLを使いこなす熟練エンジニアの矜持ではないでしょうか。ぜひ、次回のクエリ分析で、リモート側に目を向けてみてください。世界が変わるはずです。