El índice compuesto monolítico es un antipatrón clásico. El planificador no es tonto: si ve un índice de 8 columnas donde las primeras no son selectivas, puede descartarlo por completo y hacer un seq scan, que para tablas grandes es letal. He visto casos donde un índice B-tree de 5 columnas ocupaba 3GB y se usaba en menos del 1% de las consultas. La solución es segmentar: índices pequeños y específicos para cada patrón de consulta, y usar índices parciales si las condiciones son predecibles. Además, con PostgreSQL 15+ los índices B-tree deduplican entradas repetidas, pero aún así el ancho importa. Recomiendo hacer un pg_stat_user_indexes semanal y buscar índices con idx_scan bajo pero idx_tup_read alto, eso indica que se escanea mucho pero se obtienen pocas tuplas, síntoma de columnas poco selectivas al principio. ¿Alguien ha probado índices compuestos con columnas en orden inverso al de las consultas? A veces funciona mejor si la columna más selectiva va primero, aunque no coincida exactamente con el WHERE.
