【実務・中級編】統計情報コレクター – PostgreSQL

データベースの「健康診断」は誰がやってる？PostgreSQL統計情報コレクターの正体

やあ。今日もクエリのチューニングにお疲れ様。

運用に入ってしばらく経つと、「最近どうもこのクエリが遅い気がするな」とか「インデックス、本当に効いてるのかな？」と悩む夜が来るよね。そんな時、僕らは迷わず `pg_stat_user_tables` や `pg_stat_activity` を叩くわけだけど、ふと立ち止まって考えてみてほしい。

「この統計情報、一体誰が、どうやって収集してるんだ？」

今日は、PostgreSQLの縁の下の力持ち、「統計情報コレクター（Statistics Collector）」について、現場の視点から少し深掘りしてみようと思う。マニュアルを丸写しするような話は抜きにして、トラブルシューティングに直結する話をしよう。

—

1. 統計情報コレクターって何者？

簡単に言うと、PostgreSQLのプロセス群の中で「あちこちの稼働状況をメモして回る係」だ。

PostgreSQLはマルチプロセスアーキテクチャだから、個々のバックエンドプロセス（SQLを実行するプロセス）が直接ファイルを書き換えて統計情報を保持するわけじゃない。そんなことをしたらロックの競合で地獄を見るからね。

そこで登場するのが「統計情報コレクター」という専用プロセスだ。

1. 各バックエンドプロセスは、SQLを実行するたびに「今、これだけ読み込んだよ」「これだけ更新したよ」というメッセージを、UDP通信でコレクターに投げる。
2. コレクターはそれを受け取って、メモリ上でひたすら集計する。
3. 一定間隔でその集計結果をディスク（`pg_stat_tmp` ディレクトリ）に書き出す。

これが一連の流れだ。「非同期で、かつ低負荷で動く」というのが、この仕組みの最大の肝なんだよ。

2. なぜ「UDP」なのか？

ここで鋭い君なら気づいたはずだ。「UDP？パケットロスしたら統計がズレるんじゃないの？」と。

その通り。統計情報コレクターへの通知はUDPで行われる。これは「統計情報の収集のために、メインのSQL処理を待たせてはいけない」というPostgreSQLの設計思想の現れだ。

もし通知が失敗しても、データベースの整合性に致命的な影響はない。「多少の誤差はあるかもしれないが、パフォーマンスへの影響を最小限にする」というトレードオフを、PostgreSQLは選んでいるんだ。この「割り切り」こそが、PostgreSQLが堅牢で高速である理由の一つだね。

3. 実務で「統計情報の嘘」に騙されないために

現場で一番怖いのは、統計情報が古くてオプティマイザが間違った実行計画を立てることだ。

例えば、大量のデータをバッチで入れ替えた直後。「あれ、インデックスがあるのにシーケンシャルスキャンしてるぞ？」なんて時は、大抵 `ANALYZE` が追いついていない。

そんな時は、まずこうやって確認する。

— テーブルごとの最終分析時間を確認する
SELECT relname, last_analyze, last_autoanalyze
FROM pg_stat_user_tables
WHERE relname = ‘あなたの悩みのテーブル名’;

もし `last_analyze` が何日も前なら、それはもう統計情報が「化石」になっている証拠だ。手動で `ANALYZE` を打つか、`autovacuum` の設定を見直すタイミングだね。

4. チューニングのヒント：統計情報は「鮮度」が命

統計情報コレクターに関連して、パフォーマンス問題に直面したときによく触る設定が `track_activities` や `track_counts` だ。

もし本番環境で「なんだか統計情報がうまく取れていない気がする」と思ったら、まずは設定を確認してみてほしい。

— 現在の設定を確認
SHOW track_counts;

これが `off` になっていると、そもそも統計情報の収集が止まってしまう。滅多にないけど、ログ出力を極限まで削るためのチューニングでここをオフにして、そのまま忘れ去られたサーバーを何度か見たことがあるよ。気をつけよう。

最後に：統計情報は「鏡」だ

データベースの統計情報は、今のシステムの健康状態を映す鏡だ。この鏡が曇っていると、オプティマイザは道を誤り、結果としてユーザーに遅い画面を届けることになる。

統計情報コレクターは、決して派手な機能じゃない。でも、こいつが頑張ってくれているおかげで、僕らは「実行計画」という魔法のような道具を使って、効率的にクエリを走らせることができているんだ。

もし今日、クエリの遅さに悩んだら、`pg_stat_` 系のビューを眺めてみてほしい。そこには、データベースが語る「今の限界」が書かれているはずだから。

何か詰まったら、またいつでも聞いてくれ。現場からは以上だ！