正如我们在上一节中看到的，查询规划器需要对查询检索的行数进行估计，以便对查询计划做出好的选择。本节将快速浏览系统用于这些估计的统计信息。

统计信息的一个组成部分是每个表和索引中的条目总数，以及每个表和索引所占据的磁盘块数。此信息保存在表 pg_class 中，位于列 reltuples 和 relpages 中。我们可以使用类似于以下查询来查看它

SELECT relname, relkind, reltuples, relpages
FROM pg_class
WHERE relname LIKE 'tenk1%';

       relname        | relkind | reltuples | relpages
----------------------+---------+-----------+----------
 tenk1                | r       |     10000 |      345
 tenk1_hundred        | i       |     10000 |       11
 tenk1_thous_tenthous | i       |     10000 |       30
 tenk1_unique1        | i       |     10000 |       30
 tenk1_unique2        | i       |     10000 |       30
(5 rows)

在这里，我们可以看到 tenk1 包含 10000 行，其索引也包含 10000 行，但索引（不出所料）比表小很多。

出于效率原因，reltuples 和 relpages 不会即时更新，因此它们通常包含有些过期的值。它们可以被 VACUUM、ANALYZE 以及另一些 DDL 命令，例如 CREATE INDEX 更新。如果一个 VACUUM 或 ANALYZE 操作没有扫描整个表（这种情况很常见），它将根据扫描过的部分表的内容逐渐更新 reltuples 计数，从而得到一个近似值。无论如何，规划器都会调整它在 pg_class 中找到的值以匹配当前的物理表大小，从而得到一个更加接近的近似值。

大多数查询只提取表中的一部分行，这是因为 WHERE 子句限制了要检查的行。因此，规划器需要对 WHERE 子句的选择性进行估计，即满足 WHERE 子句中每个条件的行占全部行的比例。用于此任务的信息存储在系统目录 pg_statistic 中。当使用 ANALYZE 和 VACUUM ANALYZE 命令时，pg_statistic 中的条目会被更新，并且即使刚刚更新也始终是近似的。

手动检查统计信息时，不要直接查看 pg_statistic，而应查看它的视图 pg_stats。 pg_stats 被设计得更加易于阅读。此外，pg_stats 对所有人可读，而 pg_statistic 仅对超级用户可读。（这能够防止没有权限的用户通过统计信息了解其他人的表内容。 pg_stats 视图仅显示当前用户可以读取的表中的行。）例如，我们可以这样做

SELECT attname, inherited, n_distinct,
       array_to_string(most_common_vals, E'\n') as most_common_vals
FROM pg_stats
WHERE tablename = 'road';

 attname | inherited | n_distinct |          most_common_vals
---------+-----------+------------+------------------------------------
 name    | f         | -0.5681108 | I- 580                        Ramp+
         |           |            | I- 880                        Ramp+
         |           |            | Sp Railroad                       +
         |           |            | I- 580                            +
         |           |            | I- 680                        Ramp+
         |           |            | I- 80                         Ramp+
         |           |            | 14th                          St  +
         |           |            | I- 880                            +
         |           |            | Mac Arthur                    Blvd+
         |           |            | Mission                       Blvd+
...
 name    | t         |    -0.5125 | I- 580                        Ramp+
         |           |            | I- 880                        Ramp+
         |           |            | I- 580                            +
         |           |            | I- 680                        Ramp+
         |           |            | I- 80                         Ramp+
         |           |            | Sp Railroad                       +
         |           |            | I- 880                            +
         |           |            | State Hwy 13                  Ramp+
         |           |            | I- 80                             +
         |           |            | State Hwy 24                  Ramp+
...
 thepath | f         |          0 |
 thepath | t         |          0 |
(4 rows)

注意，对于相同的列显示了两行，一行对应于从 road 表（inherited=t）开始的完整的继承层次结构，而另一行只包含 road 表本身（inherited=f）。（为了简洁，我们只展示了 name 列的十个最常见的值。）

由 ANALYZE 存储在 pg_statistic 中的信息量，尤其是 most_common_vals 和 histogram_bounds 数组中每列的最大条目数，可以通过使用 ALTER TABLE SET STATISTICS 命令逐列设置，也可以通过设置 default_statistics_target 配置变量进行全局设置。现在的默认限制是 100 个条目。提高限制可能会让规划器估计更加准确，尤其是对于数据分布不规则的列，但代价是消耗更多 pg_statistic 中的空间并且计算估计需要更多的时间。相反，对于数据分布简单的列来说，一个较低的限制可能会足够。

可以在 第 68 章 中找到规划器如何使用统计信息的更多详细信息。

看到由于查询子句中使用的多列相关而导致慢查询运行错误的执行计划很常见。规划器通常假设多个条件相互独立，这在前值相关的列值时并不成立。常规统计信息因为其按独立列的性质无法捕获任何有关列间相关的信息。但是，PostgreSQL 有能力计算出可以捕获此信息的多变量统计信息。

因为列组合的数量很大，所以自动计算多变量统计信息是不切实际的。相反，可以创建扩展统计对象（通常直接称作统计对象）来指示服务器在相关的列集合中获取统计信息。

可以使用 CREATE STATISTICS 命令创建统计对象。创建这样的对象只是创建了一个目录条目，以表示对统计信息的兴趣。实际的数据收集是由 ANALYZE 执行的（无论是手动命令还是后台自动分析）。收集的值可以在 pg_statistic_ext_data 目录中进行检查。

ANALYZE 根据用于计算常规单列统计信息的表格行样本计算扩展统计信息。由于可以通过增加表格或其任何列的统计信息目标来增加样本量（如上一部分中所述），所以较高的统计信息目标通常会导致更准确的扩展统计信息，并且还会花费更多时间进行计算。

以下小节介绍了当前支持的多种类扩展统计信息。

CREATE STATISTICS stts (dependencies) ON city, zip FROM zipcodes;

ANALYZE zipcodes;

SELECT stxname, stxkeys, stxddependencies
  FROM pg_statistic_ext join pg_statistic_ext_data on (oid = stxoid)
  WHERE stxname = 'stts';
 stxname | stxkeys |             stxddependencies
---------+---------+------------------------------------------
 stts    | 1 5     | {"1 => 5": 1.000000, "5 => 1": 0.423130}
(1 row)

SELECT * FROM zipcodes WHERE city = 'San Francisco' AND zip = '94105';

SELECT * FROM zipcodes WHERE city = 'San Francisco' AND zip = '90210';

CREATE STATISTICS stts2 (ndistinct) ON city, state, zip FROM zipcodes;

ANALYZE zipcodes;

SELECT stxkeys AS k, stxdndistinct AS nd
  FROM pg_statistic_ext join pg_statistic_ext_data on (oid = stxoid)
  WHERE stxname = 'stts2';
-[ RECORD 1 ]------------------------------------------------------​--
k  | 1 2 5
nd | {"1, 2": 33178, "1, 5": 33178, "2, 5": 27435, "1, 2, 5": 33178}
(1 row)

CREATE STATISTICS stts3 (mcv) ON city, state FROM zipcodes;

ANALYZE zipcodes;

SELECT m.* FROM pg_statistic_ext join pg_statistic_ext_data on (oid = stxoid),
                pg_mcv_list_items(stxdmcv) m WHERE stxname = 'stts3';

 index |         values         | nulls | frequency | base_frequency
-------+------------------------+-------+-----------+----------------
     0 | {Washington, DC}       | {f,f} |  0.003467 |        2.7e-05
     1 | {Apo, AE}              | {f,f} |  0.003067 |        1.9e-05
     2 | {Houston, TX}          | {f,f} |  0.002167 |       0.000133
     3 | {El Paso, TX}          | {f,f} |     0.002 |       0.000113
     4 | {New York, NY}         | {f,f} |  0.001967 |       0.000114
     5 | {Atlanta, GA}          | {f,f} |  0.001633 |        3.3e-05
     6 | {Sacramento, CA}       | {f,f} |  0.001433 |        7.8e-05
     7 | {Miami, FL}            | {f,f} |    0.0014 |          6e-05
     8 | {Dallas, TX}           | {f,f} |  0.001367 |        8.8e-05
     9 | {Chicago, IL}          | {f,f} |  0.001333 |        5.1e-05
   ...
(99 rows)