「PostgreSQLのプランナって、どうやってルートを選んでるの？」コストモデルを料理に例えて解説！
こんにちは！データベースを触っていると、たまに「なんでこのクエリ、こんなに遅いの？」と頭を抱えること、ありますよね。
PostgreSQLには「プランナ」という、いわば「目的地までの最短ルートを計算するナビゲーター」が住んでいます。でも、このナビゲーター、実はときどき「いや、そっちの道は混んでるって！」という残念なルートを提案してくることがあるんです。
なぜそんなことが起きるのか？ それは、彼が「どの道がどれくらい大変か」という情報の「重み付け（コスト）」を少し勘違いしているからかもしれません。
今日は、そんなプランナの判断基準になっている「コストモデルパラメータ」について、難しい専門用語は抜きにして、お話ししてみたいと思います。
—
目的地は「データ」、移動手段は「ディスク」
データベースにとって、データを取りに行くことは「冷蔵庫から材料を取り出すこと」に似ています。
- `seq_page_cost`（シーケンシャル・ページ・コスト）
- これは「冷蔵庫の奥から手前まで、棚を順番に全部見ていく」動きです。
- 整理整頓された棚を上から下まで眺めるだけなので、実はそんなに大変じゃありません。
- `random_page_cost`（ランダム・ページ・コスト）
- これは「冷蔵庫のあちこちを、パッと開けては閉め、また別の場所を開けては閉める」という動きです。
- 毎回どこにあるか探して開ける必要があるから、順番に探すよりずっと時間がかかりますよね。
PostgreSQLは、この「順番に探すコスト」と「あちこち飛び回るコスト」を比較して、一番効率的なルートを探しているんです。
—
「デフォルト値」が万能とは限らない理由
実は、PostgreSQLの初期設定では、この「飛び回るコスト（random_page_cost）」は「順番に見るコスト（seq_page_cost）」の4倍くらい時間がかかると計算されています。
でも、考えてみてください。今の時代、HDDではなく高速な「SSD」を使っているサーバーも多いですよね？
SSDって、冷蔵庫のどこを開けても（ランダムにアクセスしても）、順番に見るのとほとんど変わらないくらい爆速なんです。それなのに、プランナが昔ながらの「SSDもHDDも同じだろう」というルールで計算していたら……。
「SSDを使っているのに、あちこち飛び回るのを極端に嫌がって、わざわざ遠回りなルートを選ぶ」
なんていう、もったいないことが起きてしまうんです。これ、すごく悲しいですよね。
—
じゃあ、どうすればいいの？
もし皆さんが、「最近なんだかクエリが遅いな」「明らかに最適じゃないルートを通っている気がする」と感じたら、このコスト設定を見直すタイミングかもしれません。
1. まずは現状を知る：`EXPLAIN` コマンドを使って、プランナがどんなルートを選んでいるか眺めてみましょう。
2. ストレージの特性を考える：SSDを使っているなら、`random_page_cost` を少し下げてみる（例えばデフォルトの 4.0 から 1.1 くらいにするなど）だけで、劇的にルートが変わることがあります。
ただし、これらは「薬」と同じで、用法用量を守らないと逆効果になることもあります。まずは検証環境で少しずつ調整して、「おっ、速くなった！」という感覚を掴むのが一番の近道ですよ。
—
まとめ：プランナと仲良くなろう
データベースのチューニングって、魔法のような裏技があるわけじゃなくて、「機械に、今の環境がいかに優秀かを教えてあげること」に尽きると思うんです。
「君が使っているのはSSDだよ、だからもっと自由に飛び回っていいんだよ」
そうやってプランナに教えてあげれば、彼はきっと、今まで以上にキビキビと、最短ルートでデータを運んできてくれるようになります。
難しく考えすぎず、まずは「このプランナ、どんな基準で考えてるのかな？」と、彼らの視点に立ってみてください。そうすれば、きっとデータベースとの距離がぐっと縮まるはずです。
それでは、また次回の記事でお会いしましょう！Happy Querying!
コメント