正如我们在上一节中看到的，查询规划器需要估计查询检索的行数，以便做出良好的查询计划选择。本节简要介绍系统用于这些估计的统计信息。

统计信息的一个组成部分是每个表和索引中的条目总数，以及每个表和索引占用的磁盘块数。此信息保存在 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 行，它的索引也是如此，但索引（毫不奇怪）比表小得多。

出于效率原因，reltuples 和 relpages 不是实时更新的，因此它们通常包含有些过时的值。它们由 VACUUM、ANALYZE 和一些 DDL 命令（如 CREATE INDEX）更新。不扫描整个表（通常情况如此）的 VACUUM 或 ANALYZE 操作将根据它扫描的表部分增量更新 reltuples 计数，从而产生一个近似值。在任何情况下，规划器都会缩放在 pg_class 中找到的值以匹配当前的物理表大小，从而获得更接近的近似值。

由于 WHERE 子句限制要检查的行，因此大多数查询仅检索表中的一小部分行。因此，规划器需要估计 WHERE 子句的选择性，即与 WHERE 子句中的每个条件匹配的行数。用于此任务的信息存储在 pg_statistic 系统目录中。 pg_statistic 中的条目由 ANALYZE 和 VACUUM ANALYZE 命令更新，即使是最新更新，也始终是近似的。

与其直接查看 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)