正如我们在上一节看到的，查询规划器需要估算查询返回的行数，以便做出最佳的查询计划选择。本节将简要介绍系统用于这些估算的统计信息。

统计信息的一个组成部分是每个表和索引的总条目数，以及每个表和索引占用的磁盘块数。这些信息保存在 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 子句的选择性，即每一项条件匹配的行所占的比例。用于此任务的信息存储在 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 占用更多空间，计算估算值也需要更多时间。反之，对于数据分布简单的列，较低的限制可能就足够了。

有关规划器如何使用统计信息的更多详细信息，请参阅 第 69 章。

由于查询子句中使用的多个列之间存在相关性，经常会导致查询运行缓慢并生成糟糕的执行计划。规划器通常假设多个条件是相互独立的，当列值相关时，这种假设就不成立了。常规统计信息由于其单列的性质，无法捕捉到跨列相关性的任何信息。然而，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)