クエリプランナの「視力」を覗き見る：pg_statsとの付き合い方
PostgreSQLと長く付き合っていると、避けて通れないのが「なぜ、このクエリはこんなに遅いプランを選択したのか？」という問いです。
もちろん、`EXPLAIN (ANALYZE, BUFFERS)` を叩くのが第一歩ですが、現場の泥沼にハマった時、我々が最後に頼るべきは「プランナが何を根拠にその選択をしたのか」という、いわばプランナの「視力」です。そこで登場するのが `pg_stats` ビューです。
今日は、このカタログビューを単なる「情報の羅列」ではなく、トラブルシューティングの強力な武器に変えるための視点について語ろうと思います。
—
なぜ pg_stats なのか？
プランナは魔法使いではありません。彼らは `ANALYZE` が収集した統計情報を頼りに、コストを計算します。もしあなたが「ここはインデックスが効くはずだ」と確信しているのに、PostgreSQLが頑なにシーケンシャルスキャンを選択するなら、十中八九、`pg_stats` に記録されたデータ分布の認識が現実と乖離しています。
例えば、`null_frac`（NULL値の割合）や `n_distinct`（一意な値の数）が、実態と大きくずれていることは珍しくありません。特に、データが偏っている（Skewed data）場合、単なる平均的な統計情報では太刀打ちできないのです。
「最頻値（MCV）」という名の地雷
多くのエンジニアが見落としがちなのが、`pg_stats` の `most_common_vals`（MCV）と `most_common_freqs`（MCF）です。
プランナは、データの分布が正規分布に近いと仮定して計算することが多いですが、現実のシステムでは特定のIDやステータスにデータが集中することがよくあります。
- 特定の顧客IDに注文が集中している
- `status = ‘processed’` が99%を占める
この状態でクエリを投げた際、プランナが「これはレアなケースだ」と誤認すれば、インデックススキャンではなく、むしろ全件探索の方が速いという誤った判断を下します。`pg_stats` でこれらのカラムを覗き、「MCVに想定通りの値が含まれているか？」を確認することは、SQLチューニングにおける最初の防衛線です。
SELECT attname, null_frac, n_distinct, most_common_vals, most_common_freqs
FROM pg_stats
WHERE tablename = ‘orders’ AND attname = ‘status’;
このクエリを叩いたとき、`most_common_freqs` の合計値が極端に低い、あるいは最新のデータ投入状況と乖離しているなら、迷わず `ANALYZE` を実行すべきです。
ヒストグラムの解像度を意識する
もう一つ、重要なのが `histogram_bounds` です。これはMCV以外の値がどのように分布しているかを示す境界線です。
データモデリングの観点で言えば、もしこのヒストグラムが非常に粗い（バケット数が少ない）場合、範囲検索（`>` や `<`）のコスト見積もりが大きく外れます。PostgreSQLのデフォルトの統計ターゲットは `100` ですが、複雑なデータ分布を持つカラムに対しては、この値を上げておくことが有効です。 ALTER TABLE orders ALTER COLUMN created_at SET STATISTICS 500; これを実行するだけで、今まで見当違いなプランを出していたクエリが、急に「覚醒」したかのように正しいプランを選択することがあります。統計情報の解像度を上げることは、プランナに対して「より精度の高いレンズ」を渡すようなものなのです。
注意すべき「落とし穴」
ただし、`pg_stats` をいじり回すことには注意が必要です。
統計ターゲットをいたずらに上げすぎると、`ANALYZE` の実行時間が肥大化し、システム全体のパフォーマンスを阻害します。また、統計情報はあくまで「スナップショット」です。バッチ処理で数百万行のデータをガツンと投入した直後の統計情報は、すでに過去の遺物かもしれません。
現場で私が大切にしているのは、「統計情報の更新頻度と、クエリの重要度のバランス」です。全てを細かく追うのではなく、ビジネスロジックの肝となるテーブル、特に「偏り」が発生しやすいカラムに対してのみ、鋭い監視の目を光らせる。これが、熟練エンジニアの距離感ではないでしょうか。
—
最後に
データベースエンジニアにとって、プランナと対話する能力は一つの芸術です。`pg_stats` を見ることは、プランナの脳内を覗き込み、「君は今、世界をこう見ているのか」と確認する作業に他なりません。
教科書的な知識も大切ですが、ぜひ一度、皆さんの環境の `pg_stats` を眺めてみてください。そこには、皆さんが設計したデータモデルが、プランナという「機械の目」にどう映っているのかという、興味深い真実が隠されています。
皆さんのクエリが、今日も最適なプランで実行されることを願っています。
コメント