Entrevista de datos: ¿Cómo usarías las estadísticas extendidas de PostgreSQL para corregir la estimación errónea de cardinalidad?

Planteamiento y alcance

Una consulta de PostgreSQL es rápida con un filtro de una sola columna, pero elige un orden de unión deficiente al filtrar customer_tier, region y status juntos. Diagnostica el error de cardinalidad, explica cuándo usar estadísticas extendidas y muestra cómo validarías la mejora y sus límites.

PostgreSQL recopila principalmente estadísticas predeterminadas por columna. Cuando las columnas están correlacionadas, la suposición de independencia del planificador puede multiplicar las selectividades incorrectamente. CREATE STATISTICS puede recopilar dependencias funcionales, combinaciones de valores más comunes o conteos distintos multivariados, pero no reemplaza un índice ni hace que cada predicado sea preciso de forma automática.

Lo que evalúa el entrevistador

• Usar EXPLAIN (ANALYZE, BUFFERS) para comparar filas estimadas y reales.
• Explicar por qué las columnas correlacionadas rompen la suposición de independencia.
• Elegir entre dependencies, mcv y ndistinct a partir de la forma del error.
• Saber que un objeto de estadísticas extendidas necesita ANALYZE para poblar datos.
• Validar los cambios de plan con cargas de trabajo representativas en lugar de agregar objetos por instinto.
• Establecer las limitaciones de muestreo, mantenimiento, expresiones y entre tablas.

Preguntas aclaratorias para hacer

1. ¿El error ocurre al filtrar, unir o agrupar?
2. ¿Cuáles son el tamaño de la tabla, el sesgo, la tasa de actualización y default_statistics_target?
3. ¿Están las tres columnas en una tabla con una correlación estable en los mismos predicados?
4. ¿El problema es la latencia, la memoria, un mal algoritmo de unión o el costo de recursos?
5. ¿Son ya apropiados los índices, las particiones y las estadísticas actuales de una sola columna?

Respuesta de 30 segundos

Ubicaría el primer error importante entre filas estimadas y reales y verificaría la frescura de las estadísticas y la distribución de los datos. Si las columnas de la misma tabla tienen una correlación estable, crearía el objeto dependencies, mcv o ndistinct adecuado más pequeño, ejecutaría ANALYZE y compararía el error de estimación, el método de unión, las lecturas de búfer y la latencia de cola con parámetros representativos. Las estadísticas extendidas mejoran el conocimiento del planificador; no reemplazan índices, particionamiento ni modelado. Las relaciones entre tablas, que varían con el tiempo o con un muestreo insuficiente requieren una gobernanza continua de datos y planes.

Análisis detallado paso a paso

1. Ubicar el error de estimación

Compara las filas estimadas y reales en cada nodo en EXPLAIN (ANALYZE, BUFFERS) y encuentra la primera divergencia de orden de magnitud. Registra los predicados, el orden de unión, el tiempo de planificación y ejecución, y los aciertos en búfer en lugar de mirar solo la latencia total.

2. Verificar las estadísticas de una sola columna y su frescura

Confirma que un ANALYZE reciente haya cubierto la tabla e inspecciona pg_stats para valores más comunes, histogramas y fracciones de nulos. Después de un gran cambio, un sesgo severo o un objetivo de estadísticas subdimensionado, corrige el muestreo y la cadencia de actualización antes de agregar un objeto multivariado.

3. Elegir un tipo de estadística

dependencies describe relaciones funcionales donde una columna implica fuertemente a otra. mcv captura combinaciones comunes que dominan la selectividad. ndistinct estima el número de combinaciones distintas y es útil para agrupaciones o deduplicaciones. Múltiples tipos pueden compartir un objeto, pero el error y la carga de trabajo deben justificar cada uno.

CREATE STATISTICS orders_customer_region_stats
  (dependencies, mcv, ndistinct)
  ON customer_tier, region, status
  FROM orders;

ANALYZE orders;

4. Revalidar el plan

Vuelve a ejecutar la consulta con parámetros similares a los de producción, estado de caché y concurrencia. Compara el error de filas en nodos clave, método de unión, memoria, archivos temporales y p95/p99. Un plan cambiado no es automáticamente mejor; verifica un uso de recursos estable a través de los valores de los parámetros.

5. Gestionar el muestreo y el tamaño del objetivo

Las estadísticas extendidas se muestrean, por lo que las combinaciones raras o los datos que cambian rápidamente pueden pasarse por alto. Mide el tiempo de ANALYZE, la carga y el beneficio antes de aumentar un objetivo para columnas calientes; no maximices el objetivo global a ciegas. Mantén el conjunto de columnas lo suficientemente pequeño para que el mantenimiento siga estando justificado.

6. Establecer límites y alternativas

Las estadísticas extendidas describen relaciones dentro de una sola tabla y no modelan directamente la correlación entre tablas ni cambian una ruta de acceso. Los errores entre tablas pueden requerir una reescritura de la consulta, preagregación, particionamiento, resultados materializados o un cambio de modelo. La correlación que varía por inquilino, temporada o transición de estado necesita monitoreo continuo.

7. Construir regresión y limpieza

Mantén planes representativos y errores de estimación en un conjunto de regresión y vuelve a ejecutarlos después de actualizaciones de PostgreSQL, migraciones y cambios de esquema. Elimina un objeto que sirva a una consulta eliminada, agregue costo de mantenimiento o no produzca una mejora medible, registrando el motivo. Vincula huellas de consultas, objetos de estadísticas, cambios de planes y latencia de producción.

Respuesta de muestra de alta calidad

Encontraría el primer nodo del plan donde las filas estimadas y reales difieran por órdenes de magnitud y confirmaría que las estadísticas de una sola columna estén frescas. Si las tres columnas de órdenes tienen una correlación estable en la misma tabla, comenzaría con el objeto dependencies o mcv más pequeño, ejecutaría ANALYZE y compararía el error de estimación, el orden de unión, las lecturas de búfer y la latencia de cola con parámetros representativos. Si el problema es un recuento de combinaciones agrupadas o deduplicadas, evaluaría ndistinct.

No trataría las estadísticas extendidas como un reemplazo de índice ni prometería resolver la correlación entre tablas. Para combinaciones raras, distribuciones cambiantes o muestras insuficientes, mediría el costo de un objetivo más alto y consideraría una reescritura de consulta, preagregación o cambio de modelo. Los planes y los errores de estimación entrarían en un conjunto de regresión para que el beneficio siga siendo observable.

Errores comunes

• Mirar solo la latencia total → pierde la fuente del error → compara filas estimadas y reales nodo por nodo.
• Habilitar todos los tipos de estadísticas por defecto → agrega mantenimiento sin pruebas → elige el conjunto más pequeño justificado por el error.
• Omitir ANALYZE → el planificador no tiene datos nuevos → incluye actualización y validación.
• Tratar las estadísticas como un índice → la consulta aún puede escanear demasiados datos → separa la estimación de las rutas de acceso.
• Probar el valor con un solo parámetro → las distribuciones y los planes varían → prueba parámetros, concurrencia y regresiones.
• Ignorar la correlación entre tablas → las estadísticas de una sola tabla no pueden corregir la unión → reescribe o gobierna el modelo.

Preguntas de seguimiento y respuestas

¿Cuándo preferirías dependencies?

Cuando una columna casi determina a otra, como una relación estable entre región y un estado restringido. Prueba primero la dependencia con datos y errores del plan.

¿En qué se diferencian mcv y ndistinct?

mcv se enfoca en combinaciones multicolumna comunes y selectividad de filtros. ndistinct se enfoca en el número de combinaciones distintas, útil para agrupaciones, deduplicación o cardinalidad de uniones.

¿Se actualiza automáticamente un objeto de estadísticas extendidas?

Sus datos son recopilados por ANALYZE, activado automática o manualmente. Que exista una definición de objeto no significa que sus datos estén frescos.

¿Por qué aumentar el objetivo de estadísticas aún podría fallar?

El muestreo puede pasar por alto combinaciones raras y las relaciones pueden cambiar con el tiempo. Mide el error de estimación y el costo de ANALYZE, luego considera una estrategia de modelo o consulta.

¿Cómo verificas regresiones?

Guarda planes para múltiples parámetros, compara el error de estimación, el uso de recursos, p95/p99 y archivos temporales, y vuelve a ejecutar tras cambios de versión, volumen de datos y esquema.

¿Cuándo deberías eliminar un objeto de estadísticas extendidas?

Elimínalo cuando la consulta haya desaparecido, la estimación no haya mejorado o el costo de mantenimiento supere el valor. Conserva la evidencia del antes y el después para que los objetos no se acumulen indefinidamente.