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

[Sandro Souza]

Bom dia/tarde Marcelo.

Grande Marcelo, depois da ajuda desses nossos grandes colaboradores, podemos
entender agora o que se passou na situação anterior.

Como você estava pesquisando apenas por um dos campos chaves (apenas parte
do índice da chave primária), o operador EXISTS não encontrou qualquer
índice aproveitável, e ficou no mesmo nível de um operador IN (sequencial).

Agora que você está utilizando os dois campos chaves (o índice completo),
fez com que o operador EXISTS encontrasse finalmente um índice aproveitável,
e "turbinou" a consulta.

Só tenho a agradecer a todos vocês por terem nos esclarecidos sobre vários
pontos que nasceram dessa questão de nosso amigo Marcelo.

Muito obrigado a todos. :D

2009/5/14 Marcelo Pinto <marcelo.marcelopinto em gmail.com>

>
> VLW GALERA.
> Consegui, graças a vocês.
> Brigadão mesmo.
> Segui a orientação do Douglas e do Carlos, usando not exists, e agora um
> select q antes dava
> Execution Time (hh:mm:ss.ssss)   00:02:03.0390
>
> agora está fazendo em
> Execution Time (hh:mm:ss.ssss)   00:00:00.0078
>
> Já tinha tentado com o exists mas não me liguei em colocar o
> p.codigo_associado = a.codigo_associado daí deu errado e desisti.
>
> Com o exists ele passou a utilizar o índice. O que melhorou e muito a sua
> execução.
> O plan ficou assim: PLAN (P INDEX (PK_PAGAMENTO)) PLAN (A NATURAL)
>
> Já coloquei em funcionamento no sistema e ficou show de bola.
>
> Muito obrigado a todos pela ajuda e sugestões.
>
> Estou extremamente agradecido a todos.
>
> [[]]'s
> Marcelo Pinto
>
>
> "Carlos H. Cantu" <listas em warmboot.com.br> escreveu
> na mensagem news:701774056.20090514071254 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
>