最简单的扩展统计信息类型跟踪函数相关性，这是数据库范式定义中使用的一个概念。如果知道 a 的值就足以确定 b 的值，则称列 b 在函数上依赖于列 a，也就是说没有两行具有相同的 a 值但具有不同的 b 值。在完全规范化的数据库中，函数相关性应该只存在于主键和超键上。但是，在实践中，许多数据集由于各种原因而未完全规范化；出于性能原因而有意进行非规范化是一个常见的例子。即使在完全规范化的数据库中，某些列之间也可能存在部分相关性，这可以表示为部分函数相关性。

函数相关性的存在直接影响某些查询中估计的准确性。如果查询同时包含对独立列和相关列的条件，则对相关列的条件不会进一步减少结果大小；但是，如果不知道函数相关性，查询计划程序将假定这些条件是独立的，从而导致结果大小低估。

为了告知计划程序有关函数相关性，ANALYZE 可以收集跨列相关性的度量。评估所有列集之间的相关性程度将非常昂贵，因此数据收集仅限于那些在使用 dependencies 选项定义的统计信息对象中同时出现的列组。建议仅为强相关的列组创建 dependencies 统计信息，以避免在 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)

这里可以看出，列 1（邮政编码）完全确定列 5（城市），因此系数为 1.0，而城市仅在 42% 的时间内确定邮政编码，这意味着许多城市（58%）由多个邮政编码表示。

在计算涉及函数相关列的查询的选择性时，计划程序使用相关性系数调整每个条件的选择性估计，以避免产生低估。

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

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

单列统计信息存储每列中的不同值的数量。当组合多列时（例如，对于GROUP BY a, b），规划器只有单列统计数据时，对不同值数量的估计通常是错误的，导致它选择错误的计划。

为了改善此类估计，ANALYZE可以收集列组的 n-distinct 统计信息。与以前一样，对每个可能的列分组执行此操作是不切实际的，因此仅为那些与使用ndistinct选项定义的统计对象中同时出现的列组收集数据。将为从列出列的集合中两个或更多列的每个可能组合收集数据。

继续前面的示例，邮政编码表中的 n-distinct 计数可能如下所示

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)

这表明有三种列组合具有 33178 个不同值：邮政编码和州；邮政编码和城市；以及邮政编码、城市和州（它们全部相等的事实是预期的，因为在这个表中邮政编码本身是唯一的）。另一方面，城市和州的组合只有 27435 个不同值。

建议仅针对实际用于分组的列组合创建 ndistinct 统计对象，并且对于这些列组合，对组数的错误估计会导致错误的计划。否则，ANALYZE 周期只是浪费。

为每列存储的另一种类型的统计数据是最常见值列表。这允许对各个列进行非常准确的估计，但可能会导致对具有多个列条件的查询进行重大错误估计。

为了改进此类估计，ANALYZE 可以收集列组合上的 MCV 列表。与函数依赖项和 n-distinct 系数类似，对每个可能的列分组执行此操作是不切实际的。在这种情况下更是如此，因为 MCV 列表（与函数依赖项和 n-distinct 系数不同）确实存储了公共列值。因此，仅为那些出现在使用 mcv 选项定义的统计对象中的列组收集数据。

继续前面的示例，邮政编码表的 MCV 列表可能如下所示（与更简单的统计类型不同，需要一个函数来检查 MCV 内容）

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)

这表明城市和州最常见的组合是华盛顿特区，实际频率（在样本中）约为 0.35%。该组合的基本频率（根据简单的每列频率计算）仅为 0.0027%，导致低估了两个数量级。

建议仅针对实际一起用于条件的列组合创建 MCV 统计对象，并且对于这些列组合，对组数的错误估计会导致错误的计划。否则，ANALYZE 和规划周期只是浪费。