¿Por qué no usa el índice?

[Angel.Matilla]

Tengo este query que ejecuto en FB 2.5.6:

Código SQL [-]
SELECT A.Codigo, A.Nombre, RDB$GET_CONTEXT('USER_TRANSACTION', 'MUNICIPIO') Municipio,
       RDB$SET_CONTEXT('USER_TRANSACTION', 'MUNICIPIO', 
                                     (SELECT DISTINCT Municipio FROM Mesas WHERE CodPrv = B.CodPrv AND Codigo = B.Mesa))
  FROM Partidos A, Resultados B, Poblacion C
 WHERE A.CodPrv = :PrvIns AND A.Codigo > 0
   AND A.CodPrv = B.CodPrv AND A.Codigo = B.Partido AND B.Proceso = :Proceso

y las estadísticas que me da IBManager me han dejado perplejo:

Las tablas implicadas en ese RDB$SET_CONTEXT están indexadas por CodPrv y Municpio (tabla Mesas) y CodPrv y Codigo como índice primario de la tabla Poblacion; ¿cómo es posible que no use ningún índice para realizar ese SELECT?

[Casimiro Notevi]

No sé si será porque todavía no me he tomado el café, pero no veo dónde usas la tabla "Poblacion".

[Casimiro Notevi]

Supongo que será esto:

Código SQL [-]
(SELECT DISTINCT c.Municipio FROM Mesas c WHERE c.CodPrv = B.CodPrv AND c.Codigo = B.Mesa))

[mamcx]

El query planner es de lo mas complejo que tiene la BD (yo estoy trabajando en uno y es algo grande, y apenas estoy en lo basico!).

El query planer puede que no use indices porque:

- La heurísticas de la BD le indican que es mas trabajoso usar indices que un scan directo (la selectividad es muy pequeña)
- Las consultas están "dentro" de funciones que el planner no puede ver. Así que si `RDB$GET_CONTEXT` es una función con un WHERE/JOIN dentro eso es invisible fuera de esa funcion
- La mayoría de los RDBMS son pésimos al usuario consultas dentro de consultas. Considera que solo `WHERE + ORDER BY+ JOIN` entra en los cálculos y las demás opciones como `HAVING, GROUP BY, ...` tal vez no.
- Un motor viejo tiene probablemente un peor query planner: Ya miraste si una version reciente "resuelve" esto?

[[duilioisola]]

Parece que en ningún momento filtras la tabla POBLACION. Por eso el planner la lee completamente.
Suongo que te da los resultados repetidos tantas veces como poblaciones tengas en esa tabla.

Código SQL [-]
SELECT A.Codigo, A.Nombre, RDB$GET_CONTEXT('USER_TRANSACTION', 'MUNICIPIO') Municipio,
       RDB$SET_CONTEXT('USER_TRANSACTION', 'MUNICIPIO', 
                                     (SELECT DISTINCT Municipio FROM Mesas WHERE CodPrv = B.CodPrv AND Codigo = B.Mesa))
FROM Partidos A, Resultados B, Poblacion C
WHERE 
A.CodPrv = :PrvIns AND 
A.Codigo > 0 AND 
A.CodPrv = B.CodPrv AND 
A.Codigo = B.Partido AND 
B.Proceso = :Proceso

Esto podría escribirse con JOINs de la siguiennte manera:

Código SQL [-]
SELECT A.Codigo, A.Nombre, RDB$GET_CONTEXT('USER_TRANSACTION', 'MUNICIPIO') Municipio,
       RDB$SET_CONTEXT('USER_TRANSACTION', 'MUNICIPIO', 
                                     (SELECT DISTINCT Municipio FROM Mesas WHERE CodPrv = B.CodPrv AND Codigo = B.Mesa))
FROM Partidos A 
JOIN Resultados B on A.CodPrv = B.CodPrv AND A.Codigo = B.Partido
JOIN Poblacion C on 1=1
WHERE 
A.CodPrv = :PrvIns AND 
A.Codigo > 0 AND 
B.Proceso = :Proceso

No entiendo qué es lo que buscas con las partes CONTEXT.

[Angel.Matilla]

Empezado por Casimiro Notevi

No sé si será porque todavía no me he tomado el café, pero no veo dónde usas la tabla "Poblacion".

Tienes razón. Como estoy probando varias formas de ejecutar esa consulta, quitando y poniendo tablas, se ve que aquí se me olvidó quitar esa tabla del query.

[Angel.Matilla]

Empezado por duilioisola

No entiendo qué es lo que buscas con las partes CONTEXT.

Como estoy haciendo pruebas, pues es una de las que he hecho.