El tipo más simple de estadísticas extendidas realiza un seguimiento de las dependencias funcionales, un concepto utilizado en las definiciones de las formas normales de las bases de datos. Decimos que la columna b depende funcionalmente de la columna a si el conocimiento del valor de a is suficiente para determinar el valor de b, es decir, no hay dos filas que tengan el mismo valor de a pero diferentes valores de b. En una base de datos totalmente normalizada, las dependencias funcionales deberían existir únicamente en las claves primarias y superclaves. Sin embargo, en la práctica muchos conjuntos de datos no están totalmente normalizados por diversas razones; la desnormalización intencionada por motivos de rendimiento es un ejemplo común. Incluso en una base de datos totalmente normalizada, puede haber una correlación parcial entre algunas columnas, lo cual se puede expresar como una dependencia funcional parcial.

La existencia de dependencias funcionales afecta directamente a la precisión de las estimaciones en ciertas consultas. Si una consulta contiene condiciones tanto en la columna independiente como en la(s) dependiente(s), las condiciones en las columnas dependientes no reducen aún más el tamaño del resultado; pero sin el conocimiento de la dependencia funcional, el planificador de consultas asumirá que las condiciones son independientes, lo que dará como resultado una subestimación del tamaño del resultado.

Para informar al planificador sobre las dependencias funcionales, ANALYZE puede recolectar mediciones de la dependencia entre columnas. Evaluar el grado de dependencia entre todos los conjuntos de columnas sería prohibitivamente costoso, por lo que la recolección de datos se limita a aquellos grupos de columnas que aparecen juntos en un objeto de estadísticas definido con la opción dependencies. Se aconseja crear estadísticas de tipo dependencies solo para grupos de columnas que estén fuertemente correlacionados, para evitar una sobrecarga innecesaria tanto en ANALYZE como en la posterior planificación de consultas.

Aquí tienes un ejemplo de recolección de estadísticas de dependencia 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 row)

Aquí se puede ver que la columna 1 (código ZIP) determina por completo la columna 5 (ciudad), por lo que el coeficiente es 1.0, mientras que la ciudad solo determina el código ZIP alrededor del 42% de las veces, lo que significa que hay muchas ciudades (58%) que están representadas por más de un código ZIP único.

Al calcular la selectividad para una consulta que involucra columnas con dependencia funcional, el planificador ajusta las estimaciones de selectividad por condición utilizando los coeficientes de dependencia para no producir una subestimación.

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

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

Las estadísticas de una sola columna almacenan el número de valores distintos en cada columna. Las estimaciones del número de valores distintos al combinar más de una columna (por ejemplo, para GROUP BY a, b) son frecuentemente erróneas cuando el planificador solo dispone de datos estadísticos de una sola columna, lo que le lleva a seleccionar planes deficientes.

Para mejorar tales estimaciones, ANALYZE puede recolectar estadísticas de n-distintos para grupos de columnas. Como antes, resulta poco práctico hacer esto para cada agrupación de columnas posible, por lo que los datos se recolectan solo para aquellos grupos de columnas que aparecen juntos en un objeto de estadísticas definido con la opción ndistinct. Se recolectarán datos para cada combinación posible de dos o más columnas del conjunto de columnas listadas.

Continuando con el ejemplo anterior, los recuentos de n-distintos en una tabla de códigos ZIP podrían verse de la siguiente manera:

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)

Esto indica que hay tres combinaciones de columnas que tienen 33178 valores distintos: código ZIP y estado; código ZIP y ciudad; y código ZIP, ciudad y estado (el hecho de que sean todos iguales es de esperar dado que el código ZIP por sí solo es único en esta tabla). Por otro lado, la combinación de ciudad y estado tiene solo 27435 valores distintos.

Se aconseja crear objetos de estadísticas de tipo ndistinct únicamente en combinaciones de columnas que realmente se utilicen para agrupar, y para las cuales una estimación errónea del número de grupos esté dando como resultado planes deficientes. De lo contrario, los ciclos de ANALYZE simplemente se desperdician.

Otro tipo de estadística almacenada para cada columna son las listas de valores más comunes (MCV, most-common value). Esto permite realizar estimaciones muy precisas para columnas individuales, pero puede dar lugar a estimaciones significativamente erróneas para consultas con condiciones en varias columnas.

Para mejorar tales estimaciones, ANALYZE puede recolectar listas de MCV sobre combinaciones de columnas. Al igual que con las dependencias funcionales y los coeficientes de n-distintos, es poco práctico hacer esto para cada agrupación de columnas posible. Aún más en este caso, ya que la lista de MCV (a diferencia de las dependencias funcionales y los coeficientes de n-distintos) sí almacena los valores comunes de las columnas. Así que los datos se recolectan únicamente para aquellos grupos de columnas que aparecen juntos en un objeto de estadísticas definido con la opción mcv.

Continuando con el ejemplo anterior, la lista de MCV para una tabla de códigos ZIP podría verse de la siguiente manera (a diferencia de los tipos de estadísticas más sencillos, se requiere una función para la inspección del contenido de la 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)

This indicates that the most common combination of city and state is Washington in DC, con una frecuencia real (en la muestra) de alrededor del 0.35%. La frecuencia base de la combinación (calculada a partir de las frecuencias simples por columna) es de solo 0.0027%, lo que da como resultado subestimaciones de dos órdenes de magnitud.

Se aconseja crear objetos de estadísticas de tipo MCV únicamente en combinaciones de columnas que realmente se utilicen juntas en condiciones, y para las cuales una estimación errónea del número de grupos esté dando como resultado planes deficientes. De lo contrario, los ciclos de ANALYZE y de planificación simplemente se desperdician.