[firebase-br] Extrema Lentidão em Consulta Firebird 5

[Luciano franca]

 O colega não usou "LEFT" não posso usar "INNER" eu não entendi o que você quiz dizer com  "+0 ou || "

veja esse link onde tem o backup do Banco feito em Firebird 3  e também os comandos SQL caso quero criar o banco já com os Dados
6.5 MB file on MEGA

Esse problema eu já tenho a mais de 3 anos e nunca consegui resolver a minha solução atualmente é muito complexa pois envolve eu colocar o Postges nos cliente que reclamam de lentidão  eu não gosto do Postgres só coloco ele em ultimo caso.

Eu continuo achando que se trata de um Bug no Firebird

Se puder dar uma analisada nesse banco só tem duas tabelas com o simples select abaixo

 SELECT CM.Codigo, CM.MERCADORIA FROM CADASTRO_MERCADORIAS CM left Join ESTOQUE E ON (E.Cod_Mercadoria = CM.codigo) left Join ESTOQUE E2 ON ( E2.Cod_Mercadoria = CM.Codigo ) Group By 1, 2


| 
| 
| 
|  |  |

 |

 |
| 
|  | 
6.5 MB file on MEGA


 |

 |

 |





    Em quinta-feira, 15 de maio de 2025 às 08:54:50 BRT, Carlos H. Cantu <listas em warmboot.com.br> escreveu:  
 
 O fato de mencionar a mesma tabela em mais de um join, por si só, não é o
problema, desde que o PLAN mostre que um índice apropriado está sendo usado em
ambas as buscas. 

No seu caso, ao tirar o segundo join, provavelmente está fazendo com que o PLAN
mude e fique mais eficiente. Vc vai ter que ir testando alterando as ordens dos
joins, usando +0 ou || '' em algumas junções, para tentar fazer com que o
Firebird escolha um plano mais eficiente.

Veja abaixo, o tempo foi muito rapido mesmo com 2 joins na mesma tabela. O PLAN
está eficiente:

Query
------------------------------------------------
select emissao, pn.codprod, pn2.codprod
from notas n
join prodnota pn on pn.id_num = n.id_num
join prodnota pn2 on pn2.id_num = n.id_num -- Repetindo o JOIN
where n.emissao > date '1.10.2024'

Plan
------------------------------------------------
PLAN JOIN (N INDEX (IDX_VENDAS_EMISSAO), PN INDEX (FK_PRODNOTA_NOTAFISCAL), PN2 INDEX (FK_PRODNOTA_NOTAFISCAL))

Query Time
------------------------------------------------
Prepare      : 0,00 ms
Execute      : 187,00 ms
Avg fetch time: 0,02 ms

Query
------------------------------------------------
select emissao, pn.codprod
from notas n
join prodnota pn on pn.id_num = n.id_num -- APENAS 1 JOIN
where n.emissao > date '1.10.2024'

Plan
------------------------------------------------
PLAN JOIN (N INDEX (IDX_VENDAS_EMISSAO), PN INDEX (FK_PRODNOTA_NOTAFISCAL))

Query Time
------------------------------------------------
Prepare      : 0,00 ms
Execute      : 62,00 ms
Avg fetch time: 0,01 ms

[]s
Carlos H. Cantu
eBook Guia de Migração para o FB 5 - www.firebase.com.br/guiafb5.php
www.FireBase.com.br - www.firebirdnews.org - blog.firebase.com.br

Lfvl>  não pode ser "INNER" tem que ser "LEFT"  eu coloquei 2 no caso mais
Lfvl> simples porém tem alguns caso onde tenho até 4 "JOINS" na mesma tabela o
Lfvl> problema é que isso no Postgres roda em segundos como coloquei no 1 email 
Lfvl> 15 segundos contra 30 minutos do Firebird

Lfvl> Eu estou achando que isso é um bug no Firebird.
Lfvl>    Em quinta-feira, 15 de maio de 2025 às 08:19:17 BRT, Armando Boza
Lfvl> Gonçalves via lista <lista em firebase.com.br> escreveu:  
Lfvl>  
Lfvl>  Bom dia, 2 LEFT JOIN para a mesma tabela?

Lfvl> Eu já tive problemas de desempenho com left join e acabei resolvendo com 
Lfvl> UNION, separei os selects e ficou bem rápido.

Lfvl> Faz um teste.

Lfvl> Em 15/05/2025 07:09, Luciano franca via lista escreveu:
>>  Acredito que encontrei o problema e não sei como resolver mesmo sem CTE não adianta
>> basta acessar a mesma tabela duas vezes para o Firebird se perder
>> se fizer algo simples como isso já vai dar problemas veja
>>
>>   Select
>>   Cp.codigo, Cp.nome
>>   From cadastro_pessoas cp
>>   left join venda v on (v.cod_cliente = cp.codigo) Left join venda v2 on (v2.cod_cliente = cp.codigo)  se eu comentar essa segunda junção é excecutado em 1 segundo
>>   Group by 1, 2