このモジュールによって収集された統計情報は、pg_stat_statementsというビューを通して利用することができます。 このビューは、1行に対して、それぞれ個々のデータベースID、ユーザID、問い合わせID、および最上位レベルの文かどうかの組み合わせを含んでいます（モジュールが記録できるSQL文の最大数まで）。 ビューの列は、表 F.22に示す通りです。

セキュリティ上の理由から、スーパーユーザとpg_read_all_statsロールの権限を持つメンバだけが、他のユーザによって実行されたSQLテキストや問い合わせのqueryidを見ることができます。 ただし、ユーザのデータベースにビューがインストールされている場合、統計情報については他のユーザから見ることができます。

計画作成が可能な問い合わせ（つまりSELECT、INSERT、UPDATE、DELETE、 MERGE）とユーティリティコマンドは、内部のハッシュ計算に従った、同一の問い合わせ構造を持つ限り、１つのpg_stat_statements項目に組み合わせられます。 典型的には、２つの問い合わせは、問い合わせの中に現れるリテラル定数の値以外、意味的に等価である場合、この目的では同一とみなされます。

他の問い合わせと合致させるために定数値が無視された場合、pg_stat_statementsの表示の中で定数は$1のようなパラメータ記号に置換されます。 問い合わせの残りのテキストは、pg_stat_statements項目に関連付いた特定のqueryidハッシュ値を持つ、１つ目の問い合わせのテキストです。

正規化が適用できる問い合わせは、pg_stat_statements内で一定の値で観察されるでしょう。 特に、エントリの割り当て解除率が高い場合にそうです。 このような事態の発生を減らすためには、pg_stat_statements.maxを増やすことを検討してください。 pg_stat_statements_infoビューは、後述のF.32.2で説明しますが、エントリの割り当て解除に関する統計情報を提供します。

一部の状況では、見た目上異なるテキストを持つ問い合わせが１つのpg_stat_statements項目にまとめられることがあります。 通常これは意味的に等しい問い合わせでのみ発生しますが、関連がない問い合わせが１つの項目にまとめられるハッシュ競合の可能性がわずかながら存在します。 （しかしこれは別のユーザまたは別のデータベースに属する問い合わせでは発生することはあり得ません。）

queryidハッシュ値は問い合わせの解析後の表現に対して計算されますので、search_pathの設定が異なる等の要因の結果として異なる意味を持つ場合、同じテキストを持つ問い合わせが別の項目として現れるという、反対もまたあり得ます。

pg_stat_statementsの消費者は、問い合わせテキストよりもより安定で信頼できる各項目への識別子として（おそらくdbidやuseridと組み合わせて）queryidを使いたいかもしれません。 しかし、queryidハッシュ値の安定性には限定された保証しかないのを理解することは重要です。 識別子は解析後の木から得られますので、その値は、とりわけ、この表現に現れる内部オブジェクト識別子の関数です。 これは少々直観に反する結果です。 例えば、pg_stat_statementsは見たところは同一の問い合わせを、それらが2つの問い合わせの実行の間に削除され再作成されたテーブルを参照しているのであれば、別個のものとみなします。 ハッシュ処理はプラットフォームのマシンアーキテクチャやその他の面の違いにも敏感です。 その上、PostgreSQLのメジャーバージョンをまたがってqueryidが安定であるとみなすのは安全ではありません。

物理WAL再生に基づくレプリケーションに参加する2つのサーバでは、同じ問い合わせに対して同一のqueryid値を持つことが期待できます。 しかし、論理レプリケーションの仕組みは、レプリカが対応する詳細すべてで同一であることを約束しません。そのため、論理レプリカの集まりで増えるコストを識別するのにqueryidは有用な識別子ではないでしょう。 疑わしければ、直接テストすることを薦めます。

一般に、queryid値は、インスタンスが同じマシンアーキテクチャで動作し、カタログメタデータの詳細が一致する場合、PostgreSQLのマイナーバージョンリリース間で安定していると仮定できます。 マイナーバージョン間で互換性が破壊されるのは、最後の手段としてのみでしょう。

代表的な問い合わせテキストの定数を置き換えるのに使われたパラメータ記号は、元の問い合わせテキストの最も大きな$nパラメータの次の数字から、もしそれがなければ$1から始まります。 ある場合には、この番号付けに影響する隠れたパラメータ記号があるかもしれないことに言及しておく価値はあります。 例えば、PL/pgSQLは関数の局所変数の値を問い合わせに挿入するために隠れたパラメータ記号を使います。そのため、SELECT i + 1 INTO jのようなPL/pgSQL文はSELECT i + $2のような代表的なテキストになります。

代表的な問い合わせテキストは外部ディスクファイルに保持され、共有メモリを消費しません。 そのため、非常に長い問い合わせテキストであっても保存に成功します。 しかし、数多くの長い問い合わせテキストが蓄積されると、外部ファイルは手に負えないくらい大きくなるかもしれません。 もしそのようなことが起きれば、回復手法として、pg_stat_statementsは問い合わせテキストを破棄することを選ぶでしょう。その結果、各queryidに関連する統計は保存されるものの、pg_stat_statementsビュー内に存在するエントリはすべてqueryフィールドがヌルになります。 もしこのようなことが起きたら、再発防止のためpg_stat_statements.maxを減らすことを検討してください。

プラン生成時と実行時の統計情報はそれぞれの終了フェーズで更新され、操作に成功した場合にのみ更新されるため、plansとcallsは常に一致するとは限りません。 例えば、SQL文のプラン生成に成功しても実行フェーズの間に失敗した場合、そのプラン生成時の統計情報のみが更新されます。 キャッシュされたプランが使用されプラン生成がスキップされた場合、実行時の統計情報のみが更新されます。

pg_stat_statementsモジュール自体の統計は記録され、pg_stat_statements_infoというビューを通して利用することができます。 このビューは、1行のみが含まれます。 ビューの列は、表 F.23に示す通りです。

このモジュールは、pg_stat_statements.maxに比例する追加の共有メモリを必要とします。 pg_stat_statements.trackにnoneが設定されていても、モジュールがロードされている限り常にこのメモリが消費されることに注意してください。

これらのパラメータはpostgresql.confの中で設定しなければなりません。 典型的な使用方法は以下のようになります。

# postgresql.conf
shared_preload_libraries = 'pg_stat_statements'

compute_query_id = on
pg_stat_statements.max = 10000
pg_stat_statements.track = all

bench=# SELECT pg_stat_statements_reset();

$ pgbench -i bench
$ pgbench -c10 -t300 bench

bench=# \x
bench=# SELECT query, calls, total_exec_time, rows, 100.0 * shared_blks_hit /
               nullif(shared_blks_hit + shared_blks_read, 0) AS hit_percent
          FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT 5;
-[ RECORD 1 ]---+--------------------------------------------------​------------------
query           | UPDATE pgbench_branches SET bbalance = bbalance + $1 WHERE bid = $2
calls           | 3000
total_exec_time | 25565.855387
rows            | 3000
hit_percent     | 100.0000000000000000
-[ RECORD 2 ]---+--------------------------------------------------​------------------
query           | UPDATE pgbench_tellers SET tbalance = tbalance + $1 WHERE tid = $2
calls           | 3000
total_exec_time | 20756.669379
rows            | 3000
hit_percent     | 100.0000000000000000
-[ RECORD 3 ]---+--------------------------------------------------​------------------
query           | copy pgbench_accounts from stdin
calls           | 1
total_exec_time | 291.865911
rows            | 100000
hit_percent     | 100.0000000000000000
-[ RECORD 4 ]---+--------------------------------------------------​------------------
query           | UPDATE pgbench_accounts SET abalance = abalance + $1 WHERE aid = $2
calls           | 3000
total_exec_time | 271.232977
rows            | 3000
hit_percent     | 98.8454011741682975
-[ RECORD 5 ]---+--------------------------------------------------​------------------
query           | alter table pgbench_accounts add primary key (aid)
calls           | 1
total_exec_time | 160.588563
rows            | 0
hit_percent     | 100.0000000000000000


bench=# SELECT pg_stat_statements_reset(0,0,s.queryid) FROM pg_stat_statements AS s
            WHERE s.query = 'UPDATE pgbench_branches SET bbalance = bbalance + $1 WHERE bid = $2';

bench=# SELECT query, calls, total_exec_time, rows, 100.0 * shared_blks_hit /
               nullif(shared_blks_hit + shared_blks_read, 0) AS hit_percent
          FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT 5;
-[ RECORD 1 ]---+--------------------------------------------------​------------------
query           | UPDATE pgbench_tellers SET tbalance = tbalance + $1 WHERE tid = $2
calls           | 3000
total_exec_time | 20756.669379
rows            | 3000
hit_percent     | 100.0000000000000000
-[ RECORD 2 ]---+--------------------------------------------------​------------------
query           | copy pgbench_accounts from stdin
calls           | 1
total_exec_time | 291.865911
rows            | 100000
hit_percent     | 100.0000000000000000
-[ RECORD 3 ]---+--------------------------------------------------​------------------
query           | UPDATE pgbench_accounts SET abalance = abalance + $1 WHERE aid = $2
calls           | 3000
total_exec_time | 271.232977
rows            | 3000
hit_percent     | 98.8454011741682975
-[ RECORD 4 ]---+--------------------------------------------------​------------------
query           | alter table pgbench_accounts add primary key (aid)
calls           | 1
total_exec_time | 160.588563
rows            | 0
hit_percent     | 100.0000000000000000
-[ RECORD 5 ]---+--------------------------------------------------​------------------
query           | vacuum analyze pgbench_accounts
calls           | 1
total_exec_time | 136.448116
rows            | 0
hit_percent     | 99.9201915403032721

bench=# SELECT pg_stat_statements_reset(0,0,0);

bench=# SELECT query, calls, total_exec_time, rows, 100.0 * shared_blks_hit /
               nullif(shared_blks_hit + shared_blks_read, 0) AS hit_percent
          FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT 5;
-[ RECORD 1 ]---+--------------------------------------------------​---------------------------
query           | SELECT pg_stat_statements_reset(0,0,0)
calls           | 1
total_exec_time | 0.189497
rows            | 1
hit_percent     |
-[ RECORD 2 ]---+--------------------------------------------------​---------------------------
query           | SELECT query, calls, total_exec_time, rows, $1 * shared_blks_hit /          +
                |                nullif(shared_blks_hit + shared_blks_read, $2) AS hit_percent+
                |           FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT $3
calls           | 0
total_exec_time | 0
rows            | 0
hit_percent     |

板垣 貴裕 <itagaki.takahiro@oss.ntt.co.jp>。 Peter Geoghegan <peter@2ndquadrant.com>により問い合わせの正規化が追加されました。