由于收集统计信息会增加查询执行的开销，因此可以配置系统是否收集信息。这由通常在postgresql.conf中设置的配置参数控制（有关设置配置参数的详细信息，请参阅第 19 章）。

参数track_activities启用对任意服务器进程当前执行命令的监控。

参数track_counts控制是否收集关于表和索引访问的统计信息。

参数track_functions启用对用户定义函数使用的跟踪。

参数track_io_timing启用对块读取和写入时间的监控。

通常，这些参数会设置在postgresql.conf中，以便它们适用于所有服务器进程，但也可以在单个会话中使用SET命令打开或关闭它们。（为防止普通用户隐藏其活动不被管理员发现，只有超级用户才能使用SET更改这些参数。）

统计收集器通过临时文件把收集到的信息传递给其他PostgreSQL进程。这些文件默认存放在由stats_temp_directory参数指定的目录中，即pg_stat_tmp。为了获得更好的性能，可以把stats_temp_directory指向基于 RAM 的文件系统，以减少物理 I/O 需求。当服务器正常关闭时，统计信息数据的永久副本会存储在pg_stat子目录中，以便在服务器重启后保留这些统计信息。当服务器启动时执行恢复时（例如立即关闭后、服务器崩溃后以及进行时间点恢复时），所有统计计数器都会被重置。

有几个预定义视图列在表 28.1中，可用于显示系统的当前状态。另有几个视图列在表 28.2中，可用于显示统计信息收集的结果。或者，也可以像第 28.2.3 节中所述那样，使用底层的统计函数构建自定义视图。

当使用统计信息来监视收集到的数据时，重要的是要意识到信息不会立即更新。每个单独的服务器进程会在转为空闲之前把新的统计计数发送给收集器，因此仍在进行中的查询或事务不会影响显示的总计。并且，收集器本身最多每隔PGSTAT_STAT_INTERVAL毫秒才会发出一份新报告一次（除非在构建服务器时做过修改，否则为 500 毫秒）。因此，显示的信息会滞后于实际活动。然而，由track_activities收集的当前查询信息始终是最新的。

另一个重要点是，当要求服务器进程显示这些统计信息中的任何一种时，它会先取回收集器进程最近发出的报告，然后在当前事务结束之前，对所有统计视图和函数一直使用这一快照。因此，只要你继续当前事务，统计信息就会显示静态信息。类似地，在事务中第一次请求这类当前查询信息时，就会收集所有会话当前查询的信息，并且在整个事务期间显示的都是同一份信息。这是一个特性，而不是一个错误，因为它允许你对统计信息执行多个查询并对结果做关联，而不必担心数字在你眼前变化。但如果希望每个查询都看到新的结果，请确保在任何事务块之外执行这些查询。或者，也可以调用pg_stat_clear_snapshot()，它会丢弃当前事务的统计快照（如果有）。下一次使用统计信息时，就会获取一个新的快照。

事务还可以在视图pg_stat_xact_all_tables、pg_stat_xact_sys_tables、pg_stat_xact_user_tables和 pg_stat_xact_user_functions中看到自己的统计信息（这些统计信息尚未传送给收集器）。这些数字不像上面所述那样起作用；相反，它们在事务期间持续更新。

每个索引的统计信息对于判断哪些索引正在被使用以及它们有多有效尤其有用。

pg_statio_视图主要用于判断缓冲区缓存的有效性。如果实际磁盘读取次数远少于缓冲区命中次数，缓存就能满足大多数读取请求，而无需调用内核。不过，这些统计信息并不能反映全部情况：由于PostgreSQL处理磁盘 I/O 的方式，不在PostgreSQL缓冲区缓存中的数据仍可能驻留在内核的 I/O 缓存中，因而仍可在不执行物理读取的情况下取得。对于希望更详细地了解PostgreSQL I/O 行为的用户，建议将PostgreSQL统计收集器与能够深入查看内核 I/O 处理情况的操作系统工具结合使用。

pg_stat_activity视图每个服务器进程将有一行，显示与该进程当前活动相关的信息。

以下示例展示如何查看等待事件：

SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event is NOT NULL;
 pid  | wait_event_type |  wait_event
------+-----------------+---------------
 2540 | Lock            | relation
 6644 | LWLockNamed     | ProcArrayLock
(2 rows)

pg_stat_replication视图为每个 WAL 发送进程包含一行，显示有关复制到该发送进程所连接备库的统计信息。这里只列出直接连接的备库；不包含下游备库的信息。

pg_stat_wal_receiver视图只包含一行，显示 WAL 接收进程从其所连接服务器接收数据的统计信息。

pg_stat_ssl视图将为每一个后端或者 WAL 发送进程包含一行，用来显示这个连接上的 SSL 使用情况。可以把它与pg_stat_activity或者pg_stat_replication通过pid列连接来得到更多有关该连接的细节。

pg_stat_archiver视图总是有一行，其中包含关于集簇的归档进程的数据。

pg_stat_bgwriter 视图始终只有一行，包含整个集簇的全局数据。

pg_stat_database视图为集簇中的每个数据库包含一行，显示整个数据库的统计信息。

pg_stat_database_conflicts视图为每个数据库包含一行，显示备库上因与恢复冲突而取消查询的数据库范围统计信息。由于主库上不会发生这些冲突，该视图只会在备库上包含信息。

pg_stat_all_tables视图将为当前数据库中的每一个表（包括 TOAST 表）包含一行，该行显示与对该表的访问相关的统计信息。pg_stat_user_tables和pg_stat_sys_tables视图包含相同的信息，但是被过滤得分别只显示用户和系统表。

pg_stat_all_indexes视图将为当前数据库中的每个索引包含一行，该行显示关于对该索引访问的统计信息。pg_stat_user_indexes和pg_stat_sys_indexes视图包含相同的信息，但是被过滤得只分别显示用户和系统索引。

索引可以被简单索引扫描、“位图”索引扫描以及优化器使用。在一次位图扫描中，多个索引的输出可以被通过 AND 或 OR 规则组合，因此当使用一次位图扫描时难以将取得的个体堆行与特定的索引关联起来。因此，一次位图扫描会增加它使用的索引的pg_stat_all_indexes.idx_tup_read计数，并且为该表增加pg_stat_all_tables.idx_tup_fetch计数，但是它不影响pg_stat_all_indexes.idx_tup_fetch。如果所提供的常量值不在优化器统计信息记录的范围之内，优化器也会访问索引来检查，因为优化器统计信息可能已经过时。

pg_statio_all_tables视图将为当前数据库中的每个表（包括 TOAST 表）包含一行，该行显示指定表上有关 I/O 的统计信息。pg_statio_user_tables和pg_statio_sys_tables视图包含相同的信息，但是被过滤得分别只显示用户表和系统表。

pg_statio_all_indexes视图将为当前数据库中的每个索引包含一行，该行显示指定索引上有关 I/O 的统计信息。pg_statio_user_indexes和pg_statio_sys_indexes视图包含相同的信息，但是被过滤得分别只显示用户索引和系统索引。

pg_statio_all_sequences视图将为当前数据库中的每个序列包含一行，该行显示在指定序列上有关 I/O 的统计信息。

pg_stat_user_functions视图将为每一个被追踪的函数包含一行，该行显示有关该函数执行的统计信息。track_functions参数控制到底哪些函数被跟踪。

其他查看统计信息的方法是直接使用查询，这些查询使用上述标准视图用到的底层统计信息访问函数。如要了解如函数名等细节，可参考标准视图的定义（例如，在psql中你可以发出\d+ pg_stat_activity）。针对每一个数据库统计信息的访问函数把一个数据库 OID 作为参数来标识要报告哪个数据库。而针对每个表和每个索引的函数要求表或索引 OID。针对每个函数统计信息的函数用一个函数 OID。注意只有在当前数据库中的表、索引和函数才能被这些函数看到。

与统计收集器相关的其他功能在表 28.18中列出。

pg_stat_get_activity是pg_stat_activity视图的底层函数，它返回一个行集合，其中包含有关每个后端进程所有可用的信息。有时只获得该信息的一个子集可能会更方便。在那些情况中，可以使用一组更老的针对每个后端的统计访问函数，这些显示在表 28.19中。这些访问函数使用一个后端 ID 号，范围从 1 到当前活动后端数目。函数pg_stat_get_backend_idset提供了一种方便的方法为每个活动后端产生一行来调用这些函数。例如，要显示PID以及所有后端当前的查询：

SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
       pg_stat_get_backend_activity(s.backendid) AS query
    FROM (SELECT pg_stat_get_backend_idset() AS backendid) AS s;