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

[Carlos H. Cantu]

Com LEFT é a mesma coisa, PLAN e tempo continuam bons:
 
Query
------------------------------------------------
select emissao, pn.codprod , pn2.codprod
from notas n
left join prodnota pn on pn.id_num = n.id_num
left join prodnota pn2 on pn2.id_num = n.id_num
where n.emissao > date '1.10.2024'
 
Plan
------------------------------------------------
PLAN JOIN (JOIN (N INDEX (IDX_VENDAS_EMISSAO), PN INDEX (FK_PRODNOTA_NOTAFISCAL)), PN2 INDEX (FK_PRODNOTA_NOTAFISCAL))
 
Query Time
------------------------------------------------
Prepare      : 0,00 ms
Execute      : 141,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

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

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

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

Lf> Eu continuo achando que se trata de um Bug no Firebird

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

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


Lf> | 
Lf> | 
Lf> | 
Lf> |  |  |

Lf>  |

Lf>  |
Lf> | 
Lf> |  | 
Lf> 6.5 MB file on MEGA


Lf>  |

Lf>  |

Lf>  |





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

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

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

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

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

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

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

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

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

Lf> []s
Lf> Carlos H. Cantu
Lf> eBook Guia de Migração para o FB 5 - www.firebase.com.br/guiafb5.php
Lf> 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

Lf>