[firebase-br] Interbase rápido x Firebird muito lento. Me ajudem com esse problema por favor.

[Rodolpho da Silva]

Sinceridade Sandro?

Concordo com os engenheiros do FB em descartar o uso de índices para consultas do tipo CAMPO NOT IN (SELECT....). A cláusula IN é utilizada em expressões cujo a finalidade é passar um pequeno conjunto de valores. Tanto é que na maioria dos SGDB's (eu ainda não fiz este teste no FB, mas creio que seja assim tmb) o limite do conjunto de valores usado em IN é 1.000. Como as consultas NOT IN (SELECT....) tem finalidade apenas de verificar a existência de dados entre um consulta externa (CAMPO NOT IN) com a consulta interna ((SELECT...)) o uso de EXISTS é fundamental para correlacionar este tipo de informação. É por isso que a maioria dos SGBD's (inclusive o FB) priorizam este tipo de consulta, utilizando os índices no seu plano de execução, uma vez em que o uso de EXISTS não precisa exportar dados da consulta interna para a consulta externa, apenas retornar VERDADEIRO ou FALSO ....

É apenas a minha opnião....;-)

Abraços!
Rodolpho



----- Original Message ----- 
  From: Sandro Souza 
  To: Carlos H. Cantu ; FireBase 
  Sent: Thursday, May 14, 2009 9:18 AM
  Subject: Re: [firebase-br]Interbase rápido x Firebird muito lento. Me ajudem com esse problema por favor.


  Bom dia/tarde Carlos.

  Grande Carlos, muito obrigado por nos esclarecer sobre esse ponto
  importante.

  Tenho a esperança que um dia o Firebird possa utilizar um mecanismo mais
  eficiente nesses tipo de pesquisa (NOT IN (<SELECT>)).

  Mais uma vez muito obrigado pelos esclarecimentos.

  2009/5/14 Carlos H. Cantu <listas em warmboot.com.br>

  > EdB> Aproveitando a oportunidade, achei muito interessante o que
  > EdB> disse nosso amigo Carlos H. Cantu sobre o operador NOT IN não
  > EdB> mais utilizar índices nessas últimas versões do Firebird para não
  > EdB> trazer resultados inconsistentes.
  >
  > Sendo mais preciso, o NOT IN não usará índices somente se a
  > construção for do tipo ... NOT IN (<select>)
  >
  > EdB> Grande Carlos, você poderia dar um exemplo de como o NOT IN
  > EdB> poderia gerar resultados inconsistentes se ainda utilizasse os
  > EdB> índices? Fiquei muito curioso a respeito desse ponto.
  >
  > Retirado do release notes do FB 2.0:
  >
  > Existence Predicates NOT IN and ALL May Be Slow
  > Firebird and, before that, InterBase, have produced incorrect results for
  > the logical existence predicates ALL
  > and NOT IN for many years. That problem has bee corrected in Firebird 2.0,
  > but the change means that
  > indexes on the inner tables cannot be used and performance may be slow
  > compared to the same query's
  > performance in V.1.5.
  >
  >
  > []s
  > Carlos H. Cantu
  > www.FireBase.com.br - www.firebirdnews.org
  > www.warmboot.com.br - blog.firebase.com.br
  >
  >
  >
  > ______________________________________________
  > FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
  > Para saber como gerenciar/excluir seu cadastro na lista, use:
  > http://www.firebase.com.br/fb/artigo.php?id=1107
  > Para consultar mensagens antigas: http://firebase.com.br/pesquisa
  >
  ______________________________________________
  FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
  Para saber como gerenciar/excluir seu cadastro na lista, use: http://www.firebase.com.br/fb/artigo.php?id=1107
  Para consultar mensagens antigas: http://firebase.com.br/pesquisa


------------------------------------------------------------------------------



  No virus found in this incoming message.
  Checked by AVG - www.avg.com 
  Version: 8.5.325 / Virus Database: 270.12.29/2114 - Release Date: 05/14/09 06:28:00