Al revisar una base de datos, dos preguntas aparecen con frecuencia: ¿qué impide guardar una combinación de datos inválida?, y ¿qué plan considera el optimizador para una consulta? PostgreSQL ofrece restricciones declarativas para reglas de integridad y EXPLAIN para inspeccionar planes. Aunque ambas herramientas ayudan a entender un sistema, no contestan la misma pregunta y no sustituyen el examen de datos, consultas y requisitos.
Usar constraints para expresar invariantes
Una constraint (restricción) limita los valores o relaciones que pueden persistirse. La documentación de PostgreSQL explica que las restricciones de tabla permiten imponer condiciones adicionales a las que ofrece el tipo de dato; si una inserción o actualización las viola, se genera un error (Constraints). Entre los mecanismos documentados están NOT NULL, CHECK, UNIQUE, clave primaria, clave foránea y exclusión.
Como criterio de trabajo, empiece por escribir la regla en lenguaje de negocio y determine si corresponde a una condición sobre una fila, unicidad o relación entre tablas. Luego elija la restricción que representa esa regla de forma mantenible. Las restricciones CHECK se evalúan sobre la fila nueva o actualizada; la documentación advierte que no deben usarse para hacer cumplir condiciones que dependan de otras filas o tablas. Para esos casos, hay mecanismos como UNIQUE, EXCLUDE o FOREIGN KEY, según la regla.
Ejemplo hipotético: una tabla de periodos registra fecha inicial y final. El equipo podría formular una regla de orden dentro de cada fila y valorar si una restricción de comprobación la expresa adecuadamente. El ejemplo no describe una base real, no resuelve los valores nulos y no reemplaza el análisis del modelo completo.
Una constraint protege una regla en el punto donde la base acepta cambios, pero su incorporación también requiere considerar los datos existentes, el comportamiento de la aplicación y el proceso de despliegue. Antes de agregarla, revise qué filas podrían incumplirla y cómo se tratarían. No confunda la intención del esquema con evidencia de que los datos históricos ya están conformes.
Usar EXPLAIN para inspeccionar un plan
PostgreSQL genera un plan de consulta y EXPLAIN permite mostrar el plan que produce el planificador. La documentación describe un plan como un árbol de nodos: por ejemplo, operaciones para recorrer tablas o índices, combinar entradas, ordenar o agregar resultados (Using EXPLAIN). Leerlo requiere conocer la consulta, la estructura y los datos que intervienen.
En la salida se presentan estimaciones del planificador, como costos, filas y ancho. Los costos son unidades arbitrarias que el optimizador usa para comparar alternativas; no equivalen directamente a una medición de tiempo de pared. Las estimaciones dependen de estadísticas y supuestos, y la documentación indica que pueden variar entre ejecuciones o tras actualizar estadísticas. Por eso, un valor aislado no permite declarar que una consulta sea rápida o lenta.
EXPLAIN ANALYZE ejecuta la instrucción y añade estadísticas reales observadas, según la documentación del comando (EXPLAIN). Esa diferencia tiene una consecuencia práctica: una sentencia de modificación puede producir efectos cuando se analiza. La documentación recomienda transacción con ROLLBACK para analizar ciertas operaciones sin conservar cambios. Aun así, use un entorno y datos seguros, evalúe funciones externas y no ejecute análisis experimental sobre información que no deba alterarse.
No intercambiar integridad y rendimiento
Una constraint pregunta si una operación respeta una regla del esquema. EXPLAIN ayuda a examinar la estrategia que el planificador considera para ejecutar una consulta. Agregar una restricción no explica por qué una consulta tarda; observar un plan tampoco hace cumplir una regla de integridad.
Como criterio de trabajo, formule primero la pregunta y el entorno de observación. Para integridad, documente la regla, filas afectadas y transición de aplicación. Para el plan, conserve la consulta representativa, parámetros, versión, estadísticas relevantes y opciones usadas. Si se utiliza ANALYZE, identifique explícitamente que la instrucción se ejecutará. La comparación de planes solo es útil si las condiciones de prueba son suficientemente comparables.
Interpretar con contexto
El plan representa la estimación del optimizador para una consulta y propiedades de datos determinadas. Cambios de distribución, estadísticas, configuración, concurrencia o hardware pueden cambiar el resultado. EXPLAIN ANALYZE añade observaciones de una ejecución, pero esa muestra tampoco caracteriza automáticamente todas las cargas ni las condiciones de producción.
Como criterio de trabajo, relacione cada nodo con una parte de la consulta y contraste filas estimadas con filas observadas cuando tenga datos seguros. Investigue filtros, joins, ordenamientos y accesos según el problema concreto. Evite agregar índices o cambiar consultas solo porque un nodo parezca inusual; confirme la hipótesis con mediciones apropiadas y evalúe el costo de mantenimiento y escritura que implican los cambios.
Qué no cubre este artículo
Esta introducción no diagnostica una consulta, propone un índice ni define un esquema universal. Los ejemplos de documentación no sustituyen medir una carga representativa; toda modificación requiere validación con la versión, datos y restricciones del sistema propio.
