【入門編】コスト見積もり – PostgreSQL

こんにちは！データベースの世界へようこそ。

PostgreSQLを使っていると、ふと「なんでこのクエリはこんなに速いんだろう？あるいは、なんでこんなに遅いんだろう？」と疑問に思うこと、ありますよね。

実はPostgreSQL、私たちがSQLを投げた瞬間、裏側で「どれが一番効率的かな？」と、ものすごい勢いで頭を働かせているんです。今日は、その裏側で行われている「コスト見積もり」というプロセスを、少しだけ覗いてみましょう。

皆さんが知らない場所へ行くとき、どうしますか？きっとGoogleマップのようなアプリを開いて、「電車で行くか」「タクシーで行くか」「徒歩で行くか」を考えますよね。

PostgreSQLもこれと全く同じことをしています。

「ユーザーがこのデータを欲しがっているな。さて、どの方法で取りに行こうか？」

1. 本棚を最初から最後まで全部めくる（全表スキャン）
2. 索引（インデックス）という名の「目次」を使って、ピンポイントでページを開く（インデックススキャン）
3. 複数の表をどういう順番で組み合わせるのが一番早いか？

PostgreSQLは、数ある候補の中から「一番コストが低い（＝楽にたどり着ける）」方法を、計算して選び出しているんです。

じゃあ、PostgreSQLはどうやって「こっちが早い」と判断しているのでしょうか？実は、彼らは「統計情報」という、いわば“カンニングペーパー”を持っています。

例えば、こんなデータです。

もし、テーブルに「田中さん」が1人しかいないなら、最初から全部めくるよりも、インデックスを使って探したほうが圧倒的に早いですよね。逆に、テーブルの半分が「田中さん」なら、目次を引く手間をかけるより、最初から全部めくっちゃったほうが早いかもしれません。

PostgreSQLは、この統計情報を元に、「CPU（頭脳）をどれくらい使うか」と「I/O（本棚から本を引っ張り出す作業）にどれくらい時間がかかるか」を予測して、「よし、今回はこのルートで行こう！」と決断しているんです。

「じゃあPostgreSQLって完璧じゃないか！」と思いますよね。でも、たまにものすごく遅いルートを選んでしまうことがあります。

それは、「統計情報が古くなっているとき」です。

さっきの例で言うと、実際には「田中さん」が100万人増えているのに、カンニングペーパーが去年の情報のままだったらどうでしょう？ PostgreSQLは「田中さんは1人しかいない」と思い込んで、非効率なルートを選んでしまいますよね。

これが、データベースの世界で「統計情報の更新（ANALYZE）」が大事と言われる理由なんです。

データベースは、決して冷たい機械ではありません。彼らは常に「一番効率の良い方法」を必死に考えてくれています。

もし皆さんのクエリが遅いと感じたら、「あ、今こいつ、ルート選びで迷っているんだな」と想像してみてください。「統計情報が古いのかな？」「検索条件にインデックスは効いているかな？」と、彼らが計算しやすい環境を整えてあげる。

そうやって少しずつ手助けしてあげると、データベースは驚くほど軽快に応えてくれるようになります。ぜひ、そんなやり取りを楽しんでみてくださいね！

それでは、また次回の記事でお会いしましょう。ハッピー・クエリライフを！