【テクニカル・上級編】 コスト見積もり – PostgreSQL

クエリプランナーの「直感」を紐解く:PostgreSQLのコスト見積もりを再考する

PostgreSQLのクエリプランナーを「ブラックボックス」として扱うのは、ある程度の規模のシステムを運用しているエンジニアなら卒業したいところですよね。

我々が `EXPLAIN ANALYZE` を叩いたとき、プランナーは一体何を基準にあの実行計画を導き出しているのか。今日は、その心臓部である「コスト見積もり」の深淵を少しだけ覗いてみましょう。

コスト見積もりの正体:CPUとI/Oの重み付け

PostgreSQLのコストモデルは、非常にシンプルかつ伝統的です。それは「シーケンシャルスキャンを1としたときの相対的なコスト」という概念に基づいています。

プランナーは、実行計画を評価する際、主に2つの要素を加算して総コストを算出します。

  • seq_page_cost: 1ページをシーケンシャルに読み込むコスト(デフォルトは1.0)
  • random_page_cost: 1ページをランダムに読み込むコスト(デフォルトは4.0)
  • cpu_tuple_cost: 1行を処理するCPUコスト
  • cpu_index_tuple_cost: インデックススキャン中に1行を処理するCPUコスト
  • cpu_operator_cost: 演算子や関数を適用するコスト

ここで重要なのは、これらの数値は「秒」のような絶対値ではなく、あくまで「見積もりのための重み」だということです。特に重要なのが `random_page_cost`。SSD全盛の現代において、これをデフォルトの4.0のままにしているのは、プランナーに「ランダムアクセスはシーケンシャルより4倍遅い」という嘘をつかせているのと同じです。現代のNVMe環境であれば、これを1.1〜1.2程度まで引き下げるだけで、インデックススキャンが劇的に選ばれやすくなる。これはチューニングの定石ですね。

統計情報の「精度」という名の幻想

コスト計算の精度を決定づけるのは、プランナーが参照する `pg_statistic` です。ここには各列のヒストグラムや、最も頻出する値(MCV)が格納されています。

しかし、ここでトラブルシューティングの勘所が働きます。例えば、`WHERE` 句で複雑な式を記述したり、相関関係のあるカラム(例:郵便番号と都道府県)でフィルタリングを行うと、プランナーは個々の統計情報を「独立したもの」と見なして計算してしまいます。

「なぜか推定行数(rows)と実測値が大幅にずれている」という場合、その多くは「カラム間の相関の欠如」に起因します。これを解消するために `CREATE STATISTICS` を駆使して拡張統計情報を作成するのは、熟練エンジニアの嗜みです。依存関係やN-distinct値をプランナーに教え込むことで、彼らの「直感」は格段に鋭くなります。

プランナーに「正しい選択」をさせるための戦略

パフォーマンストラブルの現場で、「なぜプランナーはこんな非効率なパスを選んだのか?」と頭を抱えることがよくあります。大抵の場合、プランナーが悪いのではなく、彼らに渡している材料(統計情報やコスト設定)が現実と乖離しているのです。

実務レベルで私が意識しているのは、以下の3点です。

1. 統計情報の鮮度と精度を疑う: `ANALYZE` が適切に走っているかはもちろんですが、`default_statistics_target` を調整してヒストグラムのバケット数を増やすことも検討してください。特定のスキュー(偏り)が激しいデータには必須です。
2. コスト定数の微調整: ストレージの特性に合わせて `random_page_cost` を調整する。クラウド環境では、IOPSの制限を考慮してこの値を敢えて高めに設定し、シーケンシャルスキャンを促すという逆転の発想も時には有効です。
3. プランナーの限界を認める: どんなにチューニングしても、複雑な結合やサブクエリが絡むと限界が来ます。その時は、`CTE` をうまく使って処理を分離したり、`pg_hint_plan` のような拡張機能を(最終手段として)検討する潔さも必要です。

最後に:ブラックボックスと対話する楽しさ

PostgreSQLのプランナーは、決して完璧ではありません。しかし、その「不完全さ」を理解し、統計情報という名のヒントを正しく与えてあげることで、彼らは期待以上の最高のパフォーマンスを叩き出してくれます。

「なぜそのパスを選んだのか?」という問いを自分の中で言語化できるようになると、データベースエンジニアリングは単なる作業から、プランナーとの対話という名の知的興奮へと変わります。

皆さんの現場のデータベースも、もしかしたら「もっとこうしてほしい」とヒントを待っているのかもしれませんね。次回は、この統計情報が実際にどのようにコスト算出式に組み込まれているのか、数式を交えて深掘りしてみましょう。

それでは、また。

コメント

タイトルとURLをコピーしました