该模块收集的统计信息可通过名为 pg_stat_statements 的视图获取。 对于数据库 ID、用户 ID、查询 ID 以及该语句是否为顶层语句的每一种不同组合，该视图都包含一行 （最多保存到该模块能够跟踪的不同语句的最大数量）。该视图的列见 Table F.21。

出于安全原因，只有超级用户以及具有 pg_read_all_stats 角色权限的角色才允许查看其他用户执行的查询的 SQL 文本和 queryid。不过，只要该视图已经安装在其数据库中，其他用户仍然可以查看统计信息。

可进行计划的查询（即 SELECT、INSERT、 UPDATE、DELETE 和 MERGE） 以及实用命令，只要根据内部哈希计算得出的查询结构相同，就会合并为单条 pg_stat_statements 记录。通常，如果两个查询在语义上等价， 仅在查询中出现的字面常量值不同，则会被视为相同。

当为了将某个查询与其他查询匹配而忽略常量值时，在 pg_stat_statements 的显示中，该常量会被参数符号（例如 $1）替换。查询文本的其余部分则取自第一个具有该特定 queryid 哈希值、并与该 pg_stat_statements 记录相关联的查询。

对于可以应用规范化的查询，有时仍可能在 pg_stat_statements 中看到常量值，尤其是在条目被频繁释放时。 要降低这种情况发生的可能性，可考虑增大 pg_stat_statements.max。下文 Section F.30.2 讨论的 pg_stat_statements_info 视图提供了有关条目释放的统计信息。

single pg_stat_statements entry. Normally this will happen only for semantically equivalent queries, but there is a small chance of hash collisions causing unrelated queries to be merged into one entry. （不过，这种情况不会发生在属于不同用户或不同数据库的查询之间。）

由于 queryid 哈希值是根据查询经过解析分析后的表示形式计算出来的， 相反的情况也可能发生：文本完全相同的查询，如果由于不同的 search_path 设置等因素而具有不同含义，就可能显示为不同的记录。

pg_stat_statements 的使用者可能希望使用 queryid（也许再结合 dbid 和 userid）作为每条记录比查询文本更稳定、 更可靠的标识符。不过，必须理解的是， queryid 哈希值的稳定性只得到有限保证。 由于该标识符源自解析分析后的语法树，它的取值除其他因素外，还取决于该表示形式中出现的内部对象标识符。 这会带来一些反直觉的结果。例如，如果两次查询执行之间， queries to be distinct, if they reference a table that was dropped and recreated between the executions of the two queries. 哈希过程也对机器架构差异以及平台的其他方面很敏感。 此外，也不能安全地假设 queryid 会在 PostgreSQL 的主版本之间保持稳定。

在基于物理 WAL 重放的复制中，参与复制的两个服务器对于同一查询通常可以期待获得相同的 queryid 值。然而，逻辑复制方案并不承诺在所有相关细节上保持副本完全一致，因此 queryid 并不适合作为在一组逻辑副本之间累积开销的标识符。 如有疑问，建议直接测试。

通常可以假定 queryid 值在 PostgreSQL 的小版本发布之间保持稳定，前提是实例运行在相同的机器架构上，并且目录元数据细节一致。 只有在迫不得已时，才会在小版本之间打破这种兼容性。

在代表性查询文本中，用于替换常量的参数符号从原始查询文本中最高的 $n 参数之后的下一个数字开始， 如果原文中没有，则从 $1 开始。值得注意的是，在某些情况下，可能存在会影响这一编号的隐藏参数符号。 例如，PL/pgSQL 使用隐藏参数符号将函数局部变量的值插入查询中，因此像 SELECT i + 1 INTO j 这样的 PL/pgSQL 语句， 其代表性文本可能是 SELECT i + $2。

代表性查询文本保存在外部磁盘文件中，因此不消耗共享内存。即使非常长的查询文本也可以成功存储。 不过，如果积累了很多长查询文本，该外部文件可能会膨胀到难以管理的大小。若发生这种情况， 作为一种恢复措施，pg_stat_statements 可能会选择丢弃这些查询文本， 这样 pg_stat_statements 视图中的现有记录都会显示 query 字段为 null，但与各个 queryid 相关的统计信息仍会保留。如果发生这种情况，可考虑减小 pg_stat_statements.max 以避免再次发生。

plans 和 calls 并不总是相同， 因为计划和执行统计信息分别在各自阶段结束时更新，并且只针对成功的操作。 例如，如果某条语句计划成功但在执行阶段失败，则只会更新其计划统计信息。 如果由于使用了缓存计划而跳过了计划，则只会更新其执行统计信息。

pg_stat_statements 模块自身的统计信息也会被跟踪，并通过名为 pg_stat_statements_info 的视图提供。该视图仅包含一行。 其列见 Table F.22。

该模块需要与 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     |

Takahiro Itagaki <itagaki.takahiro@oss.ntt.co.jp>。 查询规范化功能由 Peter Geoghegan <peter@2ndquadrant.com> 添加。