mlara
13-05-2008, 01:16:46
Estoy aterrado :eek:, enojado :mad:, confundido :confused:, en verdad...
, y no es juego.
En la documentación de FireBird (pág. 104) dice que la existencia de predicados NOT IN y ALL pueden ser muy lentos!!! En realidad "no pueden llegar a ser" o "no podrían serlo", porque en verdad LO SON. Parece que no han implementado la característica que hace que el motor use índices cuando se trabaja con estos predicados.
Bueno, digamos que pasa... habrá cierta forma de reemplazar un NOT IN, digamos por un NOT EXISTS bien escrito.
y entonces por qué el grito?
Pues estoy ejecutando ciertas consultas en Firebird sobre una base de datos migrada desde Paradox. Con exactamente la misma información podría decir que las consultas en Firebird son TOTALMENTE INSERVIBLES mientras que en Paradox se ejecutan en un par de segundos. Qué tipo de consultas son? Simples; este es un ejemplo:
SELECT * FROM "Tabla1" WHERE "Campo1" || "Campo2" IN (SELECT DISTINCT "Cod1" || "Cod2" FROM "Tabla2" WHERE ...)
y por qué son "prácticamente inservibles"? En este mismo momento llevo más de 30 minutos esperando por los resultados de una consulta (esto no tiene sentido, sólo hacía una prueba, ya que en consultas similares sobre otras tablas obtenía respuesta a veces en 5 minutos... finalmente se opta por parar el servicio, cerrar forzadamente las aplicaciones, y reiniciar).
Buscando un poco entendí:
Por cada registro obtenido en la consulta externa (sucede igual cuando se usa la función EXISTS), se evalúa la consulta interna, es decir: si la consulta externa devuelve mil registros (absolutamente normal), la consulta interna se abre mil veces haciendo mil evaluaciones para evaluar la condición de que los campos 1 y 2 se encuentren dentro del conjunto de resultados retornado por la consulta interna.
Me pareció muy extraño y para nada comprensible. Yo supongo que naturalmente la consulta interna debería ejecutarse una sóla vez. En memoria los resultados de esta consulta pueden conformar un resultado, si es del caso indezado, y listo. Pero no sucede así rn Firebird. Inconsebible, inadmisible...
La pregunta entonces es la siguiente, aunque creo que peco por el simple hecho de hacerla, ya que lo que no funciona pues simplemente no funciona.
¿Habrá alguna manera de agilizar estas consultas, de tal forma que el tiempo de respuesta sea razonable? :confused:
y otras preguntas obvias:
¿Sabrá alguien si el equipo de trabajo de Firebird tienen pensado solucionar tal descalabro antes de que decida usar un RDMS responsable? :mad:
PD. He probado las mismas consultas sobre Firebird 2.0.4 y Firebird 2.1.0. En ambos sistemas sucede lo mismo... TOTALMENTE INADMISIBLE... como escuché alguna vez: esto es ridículo! Es que si no se pueden usar estos predicados, entonces para qué existen.
PD2. Recuerden que en Paradox funciona de maravilla, y eso que hablo de tablas que llegan a tener hasta 1 millón de registros.
PD3. Había pensado que esperar 5 segundos era demasiado!
, y no es juego.
En la documentación de FireBird (pág. 104) dice que la existencia de predicados NOT IN y ALL pueden ser muy lentos!!! En realidad "no pueden llegar a ser" o "no podrían serlo", porque en verdad LO SON. Parece que no han implementado la característica que hace que el motor use índices cuando se trabaja con estos predicados.
Bueno, digamos que pasa... habrá cierta forma de reemplazar un NOT IN, digamos por un NOT EXISTS bien escrito.
y entonces por qué el grito?
Pues estoy ejecutando ciertas consultas en Firebird sobre una base de datos migrada desde Paradox. Con exactamente la misma información podría decir que las consultas en Firebird son TOTALMENTE INSERVIBLES mientras que en Paradox se ejecutan en un par de segundos. Qué tipo de consultas son? Simples; este es un ejemplo:
SELECT * FROM "Tabla1" WHERE "Campo1" || "Campo2" IN (SELECT DISTINCT "Cod1" || "Cod2" FROM "Tabla2" WHERE ...)
y por qué son "prácticamente inservibles"? En este mismo momento llevo más de 30 minutos esperando por los resultados de una consulta (esto no tiene sentido, sólo hacía una prueba, ya que en consultas similares sobre otras tablas obtenía respuesta a veces en 5 minutos... finalmente se opta por parar el servicio, cerrar forzadamente las aplicaciones, y reiniciar).
Buscando un poco entendí:
Por cada registro obtenido en la consulta externa (sucede igual cuando se usa la función EXISTS), se evalúa la consulta interna, es decir: si la consulta externa devuelve mil registros (absolutamente normal), la consulta interna se abre mil veces haciendo mil evaluaciones para evaluar la condición de que los campos 1 y 2 se encuentren dentro del conjunto de resultados retornado por la consulta interna.
Me pareció muy extraño y para nada comprensible. Yo supongo que naturalmente la consulta interna debería ejecutarse una sóla vez. En memoria los resultados de esta consulta pueden conformar un resultado, si es del caso indezado, y listo. Pero no sucede así rn Firebird. Inconsebible, inadmisible...
La pregunta entonces es la siguiente, aunque creo que peco por el simple hecho de hacerla, ya que lo que no funciona pues simplemente no funciona.
¿Habrá alguna manera de agilizar estas consultas, de tal forma que el tiempo de respuesta sea razonable? :confused:
y otras preguntas obvias:
¿Sabrá alguien si el equipo de trabajo de Firebird tienen pensado solucionar tal descalabro antes de que decida usar un RDMS responsable? :mad:
PD. He probado las mismas consultas sobre Firebird 2.0.4 y Firebird 2.1.0. En ambos sistemas sucede lo mismo... TOTALMENTE INADMISIBLE... como escuché alguna vez: esto es ridículo! Es que si no se pueden usar estos predicados, entonces para qué existen.
PD2. Recuerden que en Paradox funciona de maravilla, y eso que hablo de tablas que llegan a tener hasta 1 millón de registros.
PD3. Había pensado que esperar 5 segundos era demasiado!