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

统计信息的一个组成部分是每个表和索引中的条目总数，以及每个表和索引占用的磁盘块数。此信息保存在表 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 系统目录中。中的条目 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)