「なんとなく遅い」を終わらせる：PostgreSQLにおける `log_min_duration_statement` の正しい流儀
データベースのパフォーマンスチューニングにおいて、最も罪深いのは「推測」です。
「たぶんインデックスが効いていないんだろう」「おそらく統計情報が古いんだ」――夜中に叩き起こされてトラブル対応に追われているとき、そんな直感に頼った推測ほど頼りにならないものはありません。PostgreSQLでクエリを最適化する際、我々がまず手にするべき武器は、経験則ではなく「事実」です。そして、その事実を淡々と、しかし確実に積み上げてくれるのが `log_min_duration_statement` です。
今回は、この設定値を単なる「低速クエリのログ出力」としてではなく、運用環境における「定点観測」としてどう使いこなすべきか、深いレイヤーから掘り下げてみます。
—
なぜ `log_min_duration_statement` なのか
多くのエンジニアが `pg_stat_statements` を好みます。あれは素晴らしい拡張機能で、集計情報としては最高です。しかし、`pg_stat_statements` が「平均値」や「合計値」という俯瞰した視点を提供してくれるのに対し、`log_min_duration_statement` は「個別の実行」という生々しい事実を突きつけてくれます。
特に、「なぜそのクエリがその時だけ遅延したのか？」という、再現性の低いパフォーマンストラブルを追う際、実行計画（`EXPLAIN`）の断片と実際の実行時間が紐付いているログの価値は、何物にも代えられません。
運用における「閾値」の黄金律
よくある間違いは、この値を低く設定しすぎることです。「すべてのクエリを拾いたい」という欲求は、ログファイルの肥大化と、何よりI/O負荷という形でシステムに跳ね返ってきます。
- 本番環境のベストプラクティス:
まずは「許容できない遅延」の境界線を知ることから始めます。例えば、Webアプリケーションのレスポンス限界が300msなら、`log_min_duration_statement = 250`（ms）でスタートするのが定石です。
- 動的な変更:
PostgreSQLは賢いです。`ALTER SYSTEM` や `SET` を使えば、サービスを再起動することなく、特定のセッションやトランザクションに対してのみ閾値を変更できます。本番環境で「ある特定のバッチ処理だけ重い」という事象があるなら、そのトランザクションの開始時に `SET log_min_duration_statement = 0` を発行し、全クエリをログに出力させる手法は非常に有効です。
ログを「宝の山」に変えるためのアーキテクチャ的視点
ただログを垂れ流すだけでは、ログファイルは単なるゴミ捨て場になります。ここから有益な情報を抽出するために、以下の視点を持つことを強く勧めます。
1. `log_line_prefix` との共鳴:
`log_min_duration_statement` だけでは不十分です。`%p`（プロセスID）、`%t`（タイムスタンプ）、そして何より重要な `%x`（トランザクションID）を含めてください。これにより、ログ上で複数のクエリが「どのトランザクションに属しているか」を追跡可能になります。
2. `log_statement = ‘none’` との併用:
`log_statement = ‘all’` を有効にすると、すべてのクエリがログ出力され、I/OとCPU負荷が激増します。`log_min_duration_statement` を中心に据え、遅いものだけをピンポイントでキャプチャする運用が、PostgreSQLのパフォーマンスを損なわない賢い設計です。
3. `auto_explain` との合わせ技:
これが真のプロの技です。`auto_explain` モジュールを組み込むと、指定時間を超えたクエリの「実行計画」までをログに書き出すことができます。これがあれば、「遅いクエリ」を特定した瞬間に「なぜ遅いか（Seq Scanなのか、Hash Joinのコスト見積もりが外れているのか）」までが判明します。まさに、チューニングの最短距離です。
最後に：ログは「未来の自分」への手紙
データベースのチューニングにおいて、最もコストが高いのは「再現」です。あちらこちらで発生する一時的なロック待ち、バッファキャッシュの枯渇によるI/O待ち。これらは、その瞬間にログを残しておかなければ、二度と捕まえることはできません。
`log_min_duration_statement` を適切に設定しておくことは、いわば「未来の自分」を助けるための保険です。
ログを眺める際、単に「遅いクエリを探す」だけでなく、「PostgreSQLのオプティマイザがなぜこの選択をしたのか」を推測してみてください。そうすれば、あなたのチューニングスキルは、単なる「インデックスを貼る作業」から、「データベースエンジンの振る舞いを設計する仕事」へと昇華するはずです。
さあ、ログの設定を確認しましょう。あなたのシステムの「本当の姿」が、そこに記録されているはずです。
コメント