Firebird mal rendimiento en linux

[[RONPABLO]]

Hola rastafarey, el equipo en Linux depronto será multiprocesador??? de ser así tu dices que tienes instalado el super server, prueba con clasic server que es pensado en dicho tipo de equipos...

[Rudi]

Hola TJose.

Ese comentario lo hice porque utilizo muchas vistas y consultas en general que involucran la clausula NOT IN que en firebird 1.5 eran indexadas y en firebird 2 no, por eso la gente de firebird recomienda cambiarlas a NOT EXISTS y de hecho he hecho pruebas de la misma BD corriendo en firebird 1.5 y en firebird 2 y cuando le toca una consulta NOT IN en firebird 2 el rendimiento es para salir a tomar cafe mientras trae los registros. de hecho en el analizador de rendimiento de IBExpert muestra las consultas indesadas y no indexadas y cuando corre sobre firebird 1,5 todo indexado y sobre firebird 2 las consultas sobre clausulas NOT IN estan no indexadas.

A eso me refería

Gracias por preocuparte de todas formas, por cierto reinstale el debian y nada, creo que será debian, antes de cambiar distribución voy a probar con el script de jachguate para instalar firebird 2 a ver que tal. sino creo que haré una encuesta para ver entre los experimentados y entendidos (sin veteranos) del asunto cual será la mejor distribución para montar mi servidor linux con firebird.

Una vez mas gracias a todos, seguiré buscando la solución, como comenté antes, puede ser mi error pero al ver que a rastafarey le pasa lo mismo me pareció bueno preguntar sobre mi caso.

[[RONPABLO]]

Hola Rudi, reviviendo este hilo y leyendo recientemente los FAQ de Firebird me encontré con lo siguiente

Empezado por FAQ Firebird

Why is my query that uses IN or NOT IN slow?


This is an issue with Firebird optimizer. In newer Firebird versions the problem with IN is fixed, but the problem with NOT IN remains. In any case, it is safe and often faster to use EXISTS and NOT EXISTS instead. Each IN and NOT IN query can be rewritten to use EXISTS and NOT EXISTS.

Example:


select * from employee e
where e.emp_no in (select s.emp_no from SALARY_HISTORY s);

-- rewritten with EXISTS:

select * from employee e
where exists (select 1 from SALARY_HISTORY s where e.emp_no = s.emp_no);

Con lo poco que entiendo de ingles se refiere que en versiones antiguas el problema de velocidad lo tenia tanto la clausula IN y NOT IN, pero que en las nuevas versiones el IN fue optimizado pero el NOT IN continua lento... es decir que si antes era aceptable para ti ahora no debe ser tanto... Aunque tu hablaste de Indexar y esa parte aun no la he visto y depronto estoy siendo muy apresurado en emitir mi opinión... pero podrías probar si la velocidad se ve afectada o no con antiguas consultas que usan el NOT IN

[Rudi]

Hola RONPABLO,

Gracias por responder.

Recién estoy llegando de vacaciones y no he podido probar nada extra pero en las primeras pruebas que hice es evidente que en firebird 2 el uso del NOT IN es una locura, por eso decía yo lo de migrar mis aplicaciones de 1.5 a 2, cosa que tal vez no me hice entender en su momento. Ese problema (NOT IN en FB 2) ya lo tenia en la listas de cosas por hacer pero mi verdadero problema es ahora, por puro orgullo, lograr que en mi equipo debian el firebird sea mas rápido que en el equipo windows.

Gracias nuevamente.

[jachguate]

¿algún avance?

[rastafarey]

No he encontrado cual es el problema.

He hechos todo lo que me han dich he probado todo lo que sabido que me poueda dar problemas pero el enfermo no mejora.

[rastafarey]

Vamos a posicionar el post al principio ya que no se ha solucionado