こんにちは！データベースを触っていると、「あれ？これってどうやればいいの？」と首をかしげたくなる瞬間ってありますよね。
今回は、PostgreSQLを使っている時に少しだけ「もどかしい」と感じるかもしれない「外部テーブル（Foreign Table）」とインデックスのお話をしようと思います。
専門用語で難しく考える前に、まずは身近な例えから入ってみましょう。
—
本棚と「隣の部屋の図書室」
皆さんの手元に小さな本棚があると想像してください。これが皆さんが今使っている「PostgreSQLのデータベース」です。よく使う本は、取り出しやすいように「目次（インデックス）」を作って整理していますよね。
さて、ある日、あなたは「隣の部屋にある大きな図書室」の本も読みたくなりました。でも、その図書室は広すぎて、本を探すのに時間がかかります。
そこであなたは、PostgreSQLの「外部テーブル」という機能を使って、隣の図書室にある本を、自分の本棚のカタログとして見えるように設定しました。これが「外部テーブル」です。
なぜ「外部テーブル」にインデックスが作れないの？
さて、ここからが本題です。
あなたは自分の本棚には自由自在にインデックス（目次）を作れますよね。でも、「隣の図書室にある本の目次を、自分の本棚に勝手に書き込む」ことはできませんよね。
PostgreSQLの外部テーブルもこれと同じです。「外部テーブル」という名前ですが、実際はあくまで「よそのデータを見せてもらっている窓口」に過ぎません。そのため、PostgreSQL側で「このテーブルにインデックスを作って！」と命令しても、「ごめん、それは無理！」と断られてしまうんです。
「じゃあ、検索が遅いまま我慢するしかないの？」と不安になりますよね。大丈夫、解決策はあります！
—
鍵は「リモート側」にある
隣の図書室から本を探すとき、あなた自身が図書室に行って探すよりも、「図書室の司書さん」に「このタイトルの本を探して！」とお願いしたほうが、ずっと早いですよね。
PostgreSQLにおける「リモート側のインデックス」とは、まさにこの「図書室の司書さん」にお願いする作業のことなんです。
もし、隣のデータベース（リモート側）に、あらかじめそのテーブル用のインデックスが作られていたらどうなるでしょうか？
1. あなたがPostgreSQLで「この条件のデータをちょうだい！」とクエリを投げる。
2. PostgreSQLが「これは隣のデータだな。よし、あっちのデータベースに聞いてみよう」と判断する。
3. 隣のデータベースが、自分のインデックスを使ってサクッとデータを見つける。
4. 見つかった結果だけが、あなたの手元に届く。
こうなれば、ネットワーク越しに全データを引っ張ってくる必要がないので、検索スピードは劇的に速くなります！
—
初学者の皆さんに覚えておいてほしいこと
まとめると、外部テーブルを扱うときのポイントはたった2つです。
- 「インデックスは、データの持ち主（リモート側）にお願いする」
- 外部テーブルそのものにインデックスは作れません。だからこそ、データの元の場所（リモートのDB）で、ちゃんとインデックスが貼られているかを確認することが、パフォーマンスアップの第一歩です。
- 「無駄な通信を減らす工夫をする」
- せっかくリモート側にインデックスがあっても、クエリの書き方次第では「とりあえず全データ持ってきて！」という動きになってしまうことがあります。インデックスが効くような条件式（WHERE句など）を意識して書くことが、実は一番の近道なんです。
—
データベースの世界は、一見すると「ルールが厳しい」ように思えるかもしれません。でも、一つひとつを「図書室の貸し借り」のようなイメージに置き換えてみると、意外と納得できるはずです。
もし今、外部テーブルの検索が遅くて困っているなら、まずは「相手側のデータベースにインデックスはあるかな？」という視点で、一度確認してみてくださいね。
それでは、また次回の記事でお会いしましょう！Happy Querying!
コメント