O tipo mais simples de estatística estendida rastreia dependências funcionais, um conceito usado em definições de formas normais de banco de dados. Dizemos que a coluna “b” é funcionalmente dependente da coluna “a”, se o conhecimento do valor da coluna “a” for suficiente para determinar o valor da coluna “b”, ou seja, não existem duas linhas com o mesmo valor na coluna “a” e valores diferentes na coluna “b”. Em um banco de dados totalmente normalizado, as dependências funcionais devem existir apenas em chaves primárias e superchaves. Entretanto, na prática, muitos conjuntos de dados não são totalmente normalizados por vários motivos; a desnormalização intencional por motivos de desempenho é um exemplo comum. Mesmo em um banco de dados totalmente normalizado, pode haver correlação parcial entre algumas colunas, que pode ser expressa como dependência funcional parcial.

A existência de dependências funcionais afeta diretamente a precisão das estimativas em determinadas consultas. Se uma consulta contiver condições nas colunas independentes e dependentes, as condições nas colunas dependentes não reduzirão ainda mais o tamanho do resultado; mas sem conhecimento da dependência funcional, o planejador de consulta assumirá que as condições são independentes, resultando na subestimação do tamanho do resultado.

Para informar o planejador sobre dependências funcionais, o comando ANALYZE pode coletar medidas de dependência entre colunas. Avaliar o grau de dependência entre todos os conjuntos de colunas seria proibitivamente caro, então a coleta de dados é limitada aos grupos de colunas que aparecem juntas em um objeto de estatística definido com a opção dependencies (dependências). É recomendável criar estatísticas de dependências apenas para grupos de colunas fortemente correlacionados, para evitar sobrecarga desnecessária tanto no ANALYZE, quanto no planejamento de consultas posteriores.

A seguir temos um exemplo de coleta de estatísticas de dependência funcional:

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 linha)

Aqui pode-se ver que a coluna 1 (código postal), determina totalmente a coluna 5 (cidade), então o coeficiente é 1,0, enquanto a cidade determina o código postal somente cerca de 42% das vezes, significando existirem muitas cidades (58%) possuindo mais de um código postal.

Ao calcular a seletividade para uma consulta envolvendo colunas funcionalmente dependentes, o planejador ajusta as estimativas de seletividade por condição usando os coeficientes de dependência para não produzir uma subestimação.

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

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

As estatísticas mono-coluna armazenam o número de valores distintos em cada coluna. As estimativas do número de valores distintos ao combinar mais de uma coluna (por exemplo, para GROUP BY a, b), são frequentemente erradas quando o planejador tem apenas dados estatísticos mono-coluna, fazendo com que selecione incorretamente os planos.

Para melhorar estas estimativas, o comando ANALYZE pode coletar estatísticas n-distintas para grupos de colunas. Como visto antes, é impraticável fazer isto para todos os agrupamentos de colunas possíveis, então os dados são coletados apenas para os grupos de colunas que aparecem juntos em um objeto de estatística definido com a opção ndistinct. Os dados serão coletados para cada combinação possível de duas ou mais colunas do conjunto de colunas listadas.

Continuando o exemplo anterior, as contagens n-distintas em uma tabela de ZIP Code (CEP dos EUA) podem ter a seguinte aparência:

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 linha)

Este resultado indica existirem três combinações de colunas possuindo 33178 valores distintos: ZIP e estado; ZIP e cidade; e ZIP, cidade e estado (o fato de serem todos iguais é esperado, porque somente o ZIP é único nesta tabela). Por outro lado, a combinação de cidade e estado possui apenas 27.435 valores distintos.

É recomendável criar objetos de estatísticas ndistinct apenas para combinações de colunas usadas de fato para agrupamento, e para as quais a estimativa incorreta do número de grupos está produzindo planos ruins. Caso contrário, o tempo para analisar e planejar será simplesmente desperdiçado.

Outro tipo de estatística armazenada para cada coluna são as listas de valores mais comuns (most-common value, MCV). Isto permite estimativas muito precisas para colunas individuais, mas pode resultar em estimativas incorretas significativas para consultas com condições em várias colunas.

Para melhorar estas estimativas, o comando ANALYZE pode coletar listas MCV em combinações de colunas. Da mesma forma que as dependências funcionais e os coeficientes n-distintos, é impraticável fazer isto para todos os agrupamentos de colunas possíveis. Ainda mais neste caso, porque a lista MCV (ao contrário de dependências funcionais e coeficientes n-distintos) armazena os valores de coluna comuns. Portanto, os dados são coletados apenas para os grupos de colunas que aparecem juntos em um objeto de estatísticas definido com a opção mcv.

Continuando com o exemplo anterior, a lista MCV para uma tabela de códigos ZIP pode ter a seguinte aparência (ao contrário de tipos mais simples de estatísticas, é necessária uma função para inspeção do conteúdo do 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 linhas)

Isto indica que a combinação mais comum de cidade e estado é Washington DC, com frequência real (na amostra) de cerca de 0,35%. A frequência base da combinação (computada a partir das frequências simples por coluna) é de apenas 0,0027%, produzindo subestimativas de duas ordens de magnitude.

É recomendável criar objetos de estatísticas MCV apenas em combinações de colunas usadas de fato juntas em condições, e para as quais a estimativa incorreta do número de grupos está produzindo planos ruins. Caso contrário, o tempo para analisar e planejar será simplesmente desperdiçado.