[firebase-br] Extrema Lentidão em Consulta Firebird 5
Luciano franca
luapfirebird em yahoo.com.br
Quinta Maio 15 10:11:12 -03 2025
novo link permanente no Mega
https://mega.nz/file/k6gUhBpJ#4gXE7oLSW_DJdKB9UZaMUQvsI9GOPiYYJ8wqciHUVdw
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
Em quinta-feira, 15 de maio de 2025 às 09:59:10 BRT, Luciano franca via lista <lista em firebase.com.br> escreveu:
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 Dadoshttps://mega.nz/file/8uYwiBoK#y3PdspfXLOSc6wGS1c4i6vHFHCXAzgqfAvX_rY2ZGMM
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
Em quinta-feira, 15 de maio de 2025 às 09:41:34 BRT, Carlos H. Cantu via lista <lista em firebase.com.br> escreveu:
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>
______________________________________________
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://www.firebase.com.br/pesquisa_lista.html
______________________________________________
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://www.firebase.com.br/pesquisa_lista.html
Mais detalhes sobre a lista de discussão lista