【入門編】クエリプランナーのコストパラメータ – PostgreSQL

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

PostgreSQLを触っていると、「あれ、なんかクエリが遅いな？」と感じる瞬間、ありますよね。そんな時、インデックスを貼ったり、SQLを書き直したりするのは定番の対策です。でも、実は「PostgreSQLという料理人が、どうやって食材（データ）を探しに行くか」という頭の中のルールを、少し調整してあげるだけで劇的に速くなることがあるんです。

今日は、その「頭の中のルール」であるコストパラメータについて、お話ししてみようと思います。

—

クエリプランナーは「旅のルート案内人」

PostgreSQLには「クエリプランナー」という凄腕の案内人がいます。彼（彼女）は、あなたが「このデータ取ってきて！」とお願いすると、「ふむふむ、今回はこっちの道を通ったほうが早そうだな」と、最適なルートを計算してくれます。

このとき、彼らが頭の中で使っているのが「コスト」という計算式です。「こっちの道は時間がかかるから高コストだな」「こっちの道は楽勝だから低コストだな」と判断しているわけですね。

でも、この計算の基準となる「重み付け（コストパラメータ）」が、今のあなたのサーバー環境とズレていたらどうなるでしょう？そう、「わざわざ遠回りなルートを提案してくる」という悲劇が起きるんです。

—

料理にたとえると分かりやすい！

データベースを「巨大な図書館」だと想像してみてください。目的のデータを探す方法は大きく分けて2つあります。

1. シーケンシャルスキャン（全ページめくり）
本棚の端から端まで、すべてのページを順番にめくって探す方法。
2. インデックススキャン（索引を使ってジャンプ）
本の最後にある「索引」を見て、必要な情報があるページに直接飛ぶ方法。

ここで、プランナーが使う3つの大事なパラメータが登場します。

1. `seq_page_cost`（ページをめくるコスト）

「本を順番にめくる手間」です。昔のハードディスクは物理的に円盤が回っていたので、ページをめくるのは時間がかかりました。でも、今の高速なSSDなら、めくるのは一瞬ですよね？

2. `random_page_cost`（あちこちのページに飛ぶコスト）

「あっちの章、こっちのページと、索引を使って飛び回る手間」です。昔のHDDだと、ヘッドが物理的に移動する必要があったので、これが一番「重い作業」でした。でも、今のSSDはどこに飛んでも爆速です。

3. `cpu_tuple_cost`（見つけた情報を吟味するコスト）

ページを開いた後、「あ、これは違うな」「お、これが探してたやつだ！」と中身をチェックする脳の疲れ具合です。

—

なぜこの設定を気にする必要があるの？

デフォルトの設定値は、実は「昔のHDD」が基準になっていることが多いんです。

今の時代、多くのサーバーは高速なSSDを使っていますよね。それなのに、「HDD基準」の計算式でプランナーが考えると、「あちこち飛ぶ（random）のは遅いから、最初から全部のページをめくる（seq）ほうがマシだな！」と勘違いしてしまうことがあるんです。

結果、本当はインデックスを使って一瞬で終わるはずのクエリが、律儀に全データを読みに行ってしまって重くなる……これが「遅いクエリ」の隠れた原因だったりします。

—

じゃあ、どうすればいいの？

まずは、今の設定値を確認してみましょう。`SHOW`コマンドで簡単に覗けますよ。

SHOW seq_page_cost;
SHOW random_page_cost;

もし、あなたが超高速なNVMe SSDを使っているなら、`random_page_cost`をデフォルトの `4.0` から `1.1` や `1.0` に下げてみてください。

「あ、飛ぶのはもう苦じゃないんだね！じゃあインデックスをもっと積極的に使おう！」と、プランナーが賢い判断をしてくれるようになります。

注意点：魔法の杖じゃない！

ただし、このパラメータをいじるのは「最後の手段」です。

まずはインデックスが正しく効いているか、SQLの書き方は最適か、統計情報（ANALYZE）は最新かを必ず確認してください。これらの基本を飛ばしてコストパラメータだけをいじると、かえってプランナーを混乱させてしまうこともあります。

—

まとめ

データベースのチューニングは、料理の隠し味のようなものです。

`seq_page_cost` は、順番にデータを見る手間。
`random_page_cost` は、飛び飛びに見る手間。
`cpu_tuple_cost` は、中身をチェックする手間。

自分のサーバーが「どんな道具（ストレージ）」を使っているかに合わせて、このコストのバランスを調整してあげる。そうすると、PostgreSQLはもっともっと快適に働いてくれるようになりますよ。

ぜひ、皆さんの環境でも試してみてくださいね。もし「ここが分からない！」というところがあれば、いつでも気軽にコメントしてください。それでは、素敵なデータベースライフを！