如上一节所见，查询规划器需要估计查询将检索多少行，才能对查询计划做出良好选择。本节简要介绍系统用于这些估计的统计信息。

统计信息的一部分，是每个表和索引中的项总数，以及每个表和索引占用的磁盘块数。这些信息保存在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占用更多空间，并且计算估计值所需时间也会略有增加。相反，对于数据分布较简单的列，较低的上限可能已经足够。

更多规划器对统计信息的使用可参阅Chapter 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 行)