PostgreSQLの性能問題を調査した時の話です。
開発環境、テスト環境、本番環境の構築時に、log_min_duration_statement
の設定値がやや大きいことが気になり、値を小さくすることを提案しました。
しかし、レビューで「変更しない方が良い」という判断となり、
そのままリリースされました。
その後、本番環境で性能問題が発生しました。
調査を依頼されましたが、対象時間帯の遅延SQLがログに残っておらず、
原因を特定できませんでした。
もしログが残っていれば、次のような情報を確認できた可能性があります。
・どのSQLの実行に時間がかかっていたのか
・SQLの実行にどの程度の時間がかかっていたのか
・どのSQLが遅延していたのか、あるいは複数のSQLで遅延が発生していたのか
しかし、ログがなかったため、次のような原因を推測することしかできませんでした。
・統計情報の問題だったのか
・インデックスの問題だったのか
・特定SQLの実行回数が急増したのか
log_min_duration_statementとは
PostgreSQLには log_min_duration_statement というパラメータがあります。
指定した実行時間以上かかったSQLをログに出力するための設定です。
例えば、900msに設定すると、実行時間が900ms以上のSQLがログに出力されます。
ただし、値を小さくし過ぎるとログ量が増加します。
一方で、値を大きくし過ぎると、性能問題発生時に
必要な情報を取得できない可能性があります。
そのため、環境や運用ルールに応じた設定が必要です。
まとめ
今回の経験から、
「ログは出過ぎても困るが、出なさ過ぎると原因調査が難しくなる」
ということを強く実感しました。
性能問題はいつ発生するか分かりません。
PostgreSQLを運用する場合は、ログの出力量や記録されているSQLの実行時間を定期的に
確認し、log_min_duration_statement の設定値が適切かどうかを見直すことが重要です。
補足（より深く学びたい方へ）
PostgreSQLの性能調査を体系的に学びたい方は
今回のような「不要なインデックスの見極め」を含め、
実務で役立つ性能分析・チューニングの進め方を講座で体系的に解説しています。
※現在Udemyセール中のため、通常より安く受講できます。