Esta es la consulta planteada:
Código SQL
[-]SELECT * FROM "Tabla1" WHERE "Campo1" || "Campo2" IN (
SELECT DISTINCT "Cod1" || "Cod2" FROM "Tabla2" WHERE ...
)
"Campo1" +
"Campo2" deben estar dentro del conjunto de resultados, parejas diferentes compuestas por
"Cod1" +
"Cod2".
Si tengo un índice sobre
"Tabla2" conformado por los campos
"Cod1" y
"Cod2", yo espero que el sistema use el índice. Al ejecutar la consulta veo que el plan adoptado realiza un ordenamiento "natural" (
<natural_scan>), por lo que intento lo siguiente:
Código SQL
[-]SELECT * FROM "Tabla1" WHERE "Campo1" || "Campo2" IN (
SELECT DISTINCT "Cod1" || "Cod2" FROM "Tabla2" WHERE ...
PLAN ("Tabla2" INDEX ("Tabla2_Cod1Cod2"))
)
, en donde "Tabla2_Cod1Cod2" es el nombre del índice sobre dichos campos.
Entonces el sistema retorna el siguiente mensaje:
Cita:
|
index Tabla2_Cod1Cod2 cannot be used in the specified plan.
|
Entonces opto por cambiar la consulta de tal manera que no deba usar la concatenación (esto lo descubro después de hacer varias pruebas), de la siguiente manera:
Código SQL
[-]SELECT * FROM "Tabla1" T1 WHERE EXISTS (
SELECT * FROM "Tabla2" T2 WHERE (T1."Campo1" = T2."Cod1" AND T1."Campo2" = T2."Cod2") AND ...
)
y de esta manera, sin necesidad de especificar el plan, el sistema por sí sólo adopta el plan adecuado:
Cita:
|
PLAN (T2 INDEX (Tabla2_Cod1Cod2))
|
En mi consulta, que es en realidad un poco más "extensa" el tiempo de la consulta disminuyó de varios minutos a algunos segundos.
Aún así, el tiempo no me parece "adecuado". Debo seguir trabajando... mmm
Curioso
La primera consulta en Paradox sólo tomaba un par de segundos. La segunda consulta, usando EXISTS, llevó el uso del procesador al 100% y demoró varios minutos. Contrario a lo que sucede en Firebird. Aunque en Firebird la primera consulta demoraba en realidad demasiados minutos.