Простейший вид расширенной статистики отслеживает функциональные зависимости, понятие, используемое в определениях нормальных форм баз данных. Мы говорим, что столбец b функционально зависит от столбца a, если знание значения a достаточно для определения значения b, то есть нет двух строк с одинаковым значением 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-уникальные статистики для групп столбцов. Как и раньше, это непрактично делать для каждой возможной группировки столбцов, поэтому данные собираются только для тех групп столбцов, которые встречаются вместе в объекте статистики, определенном с помощью параметра 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-различных, это непрактично делать для каждой возможной группировки столбцов. Тем более в этом случае, поскольку список MCV (в отличие от функциональных зависимостей и коэффициентов n-различных) хранит общие значения столбцов. Поэтому данные собираются только для тех групп столбцов, которые встречаются вместе в объекте статистики, определенном с помощью опции 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 и циклы планирования просто тратятся.