pg_stat_statementspg_stat_statementsモジュールは、サーバで実行されたすべてのSQL文の実行時の統計情報を記録する手段を提供します。このモジュールは追加の共有メモリを必要とするため、postgresql.confのshared_preload_librariesにpg_stat_statementsを追加してモジュールをロードしなければなりません。このことは、このモジュールを追加もしくは削除するには、サーバを再起動する必要があるということを意味しています。pg_stat_statementsはロードされると、サーバのデータベース全体に渡って統計情報を記録します。この統計情報にアクセスしたり操作したりするために、このモジュールはビューpg_stat_statementsとユーティリティ関数pg_stat_statements_reset、pg_stat_statementsを提供します。pg_stat_statementsで特定のデータベースで可能になります。このモジュールにって収集された統計情報は、pg_stat_statementsというビューを通して利用することができます。このビューは、1行に対して、それぞれ個々のデータベースID、ユーザID、および問い合わせIDを含んでいます(モジュールが記録できるSQL文の最大数まで)。ビューの列は、表F.22「pg_stat_statementsの列」に示す通りです。(track_io_timingが有効な場合。(track_io_timingが有効な場合。無効であればゼロ)セキュリティ上の理由から、スーパーユーザ以外のユーザは、他のユーザによって実行されたSQLテキストや問い合わせのqueryidを見ることができません。ユーザのデータベースにビューがインストールされている場合、統計情報についてはそれらユーザから見ることができます。計画作成が可能な問い合わせ(つまりSELECT、INSERT、UPDATE、DELETE)は、内部のハッシュ計算に従った、同一の問い合わせ構造を持つ限り、1つのpg_stat_statements項目に組み合わせられます。典型的には、2つの問い合わせは、問い合わせの中に現れるリテラル定数の値以外、意味的に等価である場合、この目的では同一とみなされます。ユーティリティコマンド(つまりこの他のコマンドすべて)は問い合わせ文字列のテキストを基に厳密に比較されます。他の問い合わせと合致させるために定数値が無視された場合、pg_stat_statementsの表示の中で定数は?に置換されます。問い合わせの残りのテキストは、pg_stat_statements項目に関連付いた特定のqueryidハッシュ値を持つ、1つ目の問い合わせのテキストです。一部の状況では、見た目上異なるテキストを持つ問い合わせが1つのpg_stat_statements項目にまとめられることがあります。通常これは意味的に等しい問い合わせでのみ発生しますが、関連がない問い合わせが1つの項目にまとめられるハッシュ競合の可能性がわずかながら存在します。(しかしこれは別のユーザまたは別のデータベースに属する問い合わせでは発生することはあり得ません。)queryidハッシュ値は問い合わせの解析後の表現に対して計算されますので、search_pathの設定が異なる等の要因の結果として異なる意味を持つ場合、同じテキストを持つ問い合わせが別の項目として現れるという、反対もまたあり得ます。pg_stat_statementsの消費者は、問い合わせテキストよりもより安定で信頼できる各項目への識別子として(おそらくdbidやuseridと組み合わせて)queryidを使いたいかもしれません。queryidハッシュ値の安定性には限定された保証しかないのを理解することは重要です。識別子は解析後の木から得られますので、その値は、とりわけ、この表現に現れる内部オブジェクト識別子の関数です。これは少々直観に反する結果です。pg_stat_statementsは見たところは同一の問い合わせを、それらが2つの問い合わせの実行の間に削除され再作成されたテーブルを参照しているのであれば、別個のものとみなします。ハッシュ処理はプラットフォームのマシンアーキテクチャやその他の面の違いにも敏感です。その上、PostgreSQLのメジャーバージョンをまたがってqueryidが安定であるとみなすのは安全ではありません。経験上、queryid値は、基礎となるサーバのバージョンとカタログメタデータの詳細が全く同じである限り、安定していて比較可能とみなすことができます。物理WAL再生に基づくレプリケーションに参加する2つのサーバでは、同じ問い合わせに対して同一のqueryid値を持つことが期待できます。論理レプリケーションの仕組みは、レプリカが対応する詳細すべてで同一であることを約束しません。そのため、論理レプリカの集まりで増えるコストを識別するのにqueryidは有用ではありません。疑わしければ、直接テストすることを薦めます。代表的な問い合わせテキストは外部ディスクファイルに保持され、共有メモリを消費しません。そのため、非常に長い問い合わせテキストであっても保存に成功します。長い問い合わせテキストが蓄積されると、外部ファイルは手に負えないくらい大きくなるかもしれません。そのようなことが起きれば、回復手法として、pg_stat_statementsは問い合わせテキストを破棄することを選ぶでしょう。その結果、各queryidに関連する統計は保存されるものの、pg_stat_statementsビュー内に存在するエントリはすべてqueryフィールドがヌルになります。このようなことが起きたら、再発防止のためpg_stat_statements.maxを減らすことを検討してください。voidpg_stat_statements_resetはpg_stat_statementsによってこれまでに収集したすべての統計情報を削除します。デフォルトでは、この関数はスーパーユーザのみ実行することができます。recordpg_stat_statementsビューは同じくpg_stat_statementsという名前の関数の項で定義されています。falseと指定することで問い合わせテキストを省略することが可能です(すなわち、ビューのquery列に対応するOUT引数はNULLを返します)。この機能は不定長の問い合わせテキストを繰り返し取得するオーバヘッドを避けたいと考える外部のツールをサポートすること意図したものです。そのようなツールは代わりに、それがpg_stat_statements自身が行なっていることのすべてですので、各項目で最初に観察された問い合わせテキストをキャッシュし、必要とされる問い合わせテキストのみを取得できます。サーバは問い合わせテキストをファイルに格納しますので、この方法はpg_stat_statementsデータの繰り返しの検査に対する物理I/Oを減らすでしょう。(integer)pg_stat_statements.maxは、このモジュールによって記録されるSQL文の最大数(すなわち、pg_stat_statementsビューにおける行の最大数)です。これを超えて異なるSQL文を検出した場合は、最も実行回数の低いSQL文の情報が捨てられます。デフォルトは5000です。このパラメータはサーバの起動時にのみ指定できます。(enum)pg_stat_statements.trackは、どのSQL文をモジュールによって計測するかを制御します。topを指定した場合は(直接クライアントによって発行された)最上層のSQL文を記録します。allは(関数の中から呼び出された文などの)入れ子になった文も記録します。noneは文に関する統計情報収集を無効にします。デフォルトはtopです。この設定はスーパーユーザだけが変更できます。(boolean)pg_stat_statements.track_utilityは、このモジュールがユーティリティコマンドを記録するかどうかを指定します。SELECT、INSERT、UPDATEおよびDELETE以外のすべてです。デフォルトはonです。この設定はスーパーユーザのみが変更できます。(boolean)pg_stat_statements.saveは、サーバを終了させる際に文の統計情報を保存するかどうかを指定します。offの場合、統計情報は終了時に保存されず、サーバ開始時に再読み込みもされません。デフォルト値はonです。このパラメータはpostgresql.confファイル、またはサーバコマンドラインでのみ設定できます。このモジュールは、pg_stat_statements.maxに比例する追加の共有メモリを必要とします。pg_stat_statements.trackにnoneが設定されていても、モジュールがロードされている限り常にこのメモリが消費されることに注意してください。これらのパラメータはpostgresql.confの中で設定しなければなりません。典型的な使用方法は以下のようになります。<itagaki.takahiro@oss.ntt.co.jp>。<peter@2ndquadrant.com>により問い合わせの正規化が追加されました。pgstattuple。