「検索の旅」を最適化せよ！PostgreSQLのコスト見積もりって何だろう？
こんにちは！データベースの世界へようこそ。
普段、PostgreSQLを使っていると、「あれ？なんでこのクエリ、こんなに遅いの？」と首をかしげたくなること、ありますよね。実は、PostgreSQLの頭脳である「プランナ（実行計画を作る担当者）」は、膨大なデータの海から最短ルートを見つけ出すために、常に「コスト計算」を行っているんです。
今日は、そのプランナが何を考えてルートを選んでいるのか、日常の風景に例えて紐解いていきましょう。
—
プランナは「旅の計画係」
PostgreSQLのプランナは、言ってみれば「目的地まで一番早く着くルートを提案する旅行代理店のスタッフ」です。
彼らは「A地点からB地点へ移動するのに、電車で行くべきか、それともタクシーで行くべきか」を必死に計算しています。その計算の根拠になっているのが、実は皆さんの設定ファイルにあるいくつかの「コスト定数」なんです。
1. `seq_page_cost`：地道な「全件踏破」のコスト
これは、データを端から端まで順番に読み込むコストのこと。例えるなら、「広い図書館の棚を、端から端まで歩いて本を探す」ようなものです。
歩くだけなので予測は簡単ですが、棚が何千個もあると、さすがに時間がかかりますよね。
2. `random_page_cost`：飛び石の「ランダムアクセス」のコスト
これは、インデックスを使って特定の場所へピンポイントで飛ぶ時のコスト。「図書館の目次を見て、特定の棚までダッシュで駆けつける」ようなイメージです。
一見早そうですが、急に立ち止まったり走ったりするので、体力（システム負荷）を消耗します。昔のHDD時代は「飛び石移動は遅い」のが常識だったので、この値は高めに設定されていました。
3. `cpu_tuple_cost`：読み込んだ後の「選別作業」
データを見つけた後、「お目当ての本かな？」と中身を確認するコストです。「本を手に取って、内容をパラパラめくって確認する」作業ですね。
データ量が膨大だと、この確認作業が積もり積もって重荷になってきます。
—
なぜ設定を意識する必要があるの？
「じゃあ、その数値をいじれば速くなるの？」と思うかもしれません。結論から言うと、「あなたのシステムの『足』に合わせて調整してあげると、劇的に良くなることがある」んです。
例えば、最近のサーバーは高性能なSSDを使っていることが多いですよね。
昔は「ランダムアクセスは遅いから避けよう（`random_page_cost`を高く）」という判断が正解でしたが、SSDなら「飛び石移動なんてお手の物！」です。
ここで、もし昔のままの数値を使い続けていたらどうなるでしょう？
プランナは「ランダムアクセスはコストが高いからやめておこう。全部順番に読んだほうがマシだ」と判断し、本来なら一瞬で見つかるはずのデータを、わざわざ全件スキャンして読み込んでしまう……なんていう「空回り」が起きてしまうんです。
—
調整のコツは「無理をしないこと」
もちろん、この数値を闇雲にいじればいいというわけではありません。
- まずは現状を知る: `EXPLAIN ANALYZE` コマンドを使って、今のプランナがどう考えているのか覗いてみましょう。
- 少しずつ変える: 劇的な変化を求めすぎず、環境の変化（ストレージの変更など）に合わせて慎重に調整するのが、熟練のエンジニアの流儀です。
- 「なぜそうなった？」を考える: 数値をいじる前に、「そもそもインデックスが効いていないのでは？」と疑うことも大切です。
—
おわりに
データベースのチューニングって、なんだか難しそうな呪文のように聞こえますよね。でも、こうして「プランナという旅行代理店が、どんな基準でルートを選んでいるか」を想像してみると、少しだけ身近に感じられませんか？
PostgreSQLは、あなたの設定次第で、とびきり優秀な執事にも、ちょっと頑固なパートナーにもなります。ぜひ、彼らの「思考回路」を理解して、最高のパフォーマンスを引き出してあげてくださいね。
皆さんのクエリが、今日も最短ルートで見つかりますように！それでは、また次回のブログでお会いしましょう。
コメント