Qué estrategia seguir en PostgreSQL: optimizar índices o cambiar el enfoque?

[VioletYB]

Llevo unas semanas peleándome con un problema de rendimiento en una aplicación interna que usa PostgreSQL, y me encuentro en un punto donde no sé si seguir ajustando índices o cambiar el enfoque por completo. La consulta principal, que es un JOIN complejo con varias tablas, se ralentiza de forma dramática cuando los datos superan un cierto volumen, incluso teniendo claves primarias y foráneas bien definidas. He estado leyendo sobre la normalización de bases de datos y si en casos como este podría ser contraproducente, pero las pruebas que hago no me dan una respuesta clara.

[AbigailB]

Analizándolo desde el plan de ejecución: el cuello de botella parece estar en el JOIN, no sólo en la falta de índices. Normalización ha hecho bien su trabajo para la consistencia, pero cuando los datos crecen el planner puede elegir operaciones costosas. Empieza por EXPLAIN ANALYZE del JOIN completo y compara planes con diferentes índices (compositos, expresiones, filtros parciales) para ver qué ruta es más barata. A veces no se trata de añadir más índices sino de entender cómo se cruzan las tablas en el plan.

[JeffreyTW]

La normalización no es una varita mágica; podría estar ocultando un problema de lectura si las tablas están muy normalizadas y obligan a muchos joins. Denormalización selectiva, vistas materializadas o particionado pueden ser enfoques útiles cuando el dato crece. ¿Y si el cuello de botella está en la propagación de datos a través de las claves foráneas en un join grande?

[Zachary_H]

Me está agotando este tema; cada vez que suben los datos, la consulta se ralentiza de golpe. Normalización suena ideal en teoría, pero en producción se traduce en más consultas y más coste de lectura. Quizá el camino no sea sólo ajustar índices, sino revisar el patrón de acceso y la distribución de lecturas. ¿Qué opinas de mirar el plan de ejecución como un mapa en vez de una lista de reglas?

[Oliver.M]

Replanteo: a veces el problema no es el SQL sino cómo mides rendimiento a gran escala. En lugar de seguir añadiendo índices, prueba particionamiento, vistas materializadas o un esquema orientado al acceso para ese JOIN. La distribución de datos importa, sobre todo cuando hay datos viejos en particiones. ¿Y si reestructuramos el problema desde una arquitectura de datos más amplia?

[BrandonAM]

Los índices ayudan, pero si el plan muestra un hash join o un merge join caro, quizá hay que revisar estadísticas y cardinalidad. Normalización puede estar empujando hacia más lecturas, no necesariamente mejores tiempos. Palabra clave: normalización.

[Gregory.S]

Una visión diferente: tal vez el problema no es la base en sí, sino el volumen de datos que llega sin filtrar. Considera limitar, paginar o particionar, o incluso mover parte del trabajo a una capa de caché. No descartes la idea de una arquitectura de datos más amplia.