Observação: Observando os outros dois planos, parece-me que as querys trazem resultados diferentes.
Considerações sobre minha análise: Eu analisei o plano: https://explain.depesz.com/s/MVw1 Segue minha análise. Caso eu esteja errado, sintam-se à vontade para me corrigir, assim eu aprendo junto: O join da tabela "nfe_empresa ng"(2) com a tabela "nfe_ident ni"(1) resulta em "2878 linhas"(3). Para cada linha do resultado, é feito um "join" com "nfe n"(4) e (5) identificado por loops=2878 Depois com (ver Nested Loop) nfe_emitente ne: Para cada linha de "n" do join é feito uma busca no índice loops=2878 (creio que o problema esteja aqui, pois aumenta muito o *tempo* ) " -> Nested Loop (cost=755.68..175486.51 rows=10 width=204) (actual time=3691.454..12259.435 rows=2878 loops=1)" Depois com (ver Nested Loop) nfe_destinatario nd: Para cada linha de "n" do join é feito uma busca no índice loops=2878 Depois com (ver Nested Loop) nfe_transp nt: Para cada linha de "n" do join é feito uma busca no índice loops=2878 Por último é feito join do resultado dos passos anteriores com o subplano 9 (que não é tão custoso, pois não retorna nenhuma linha) (1)->Index Scan using pk_nfe_ident on nfe_ident ni (cost=0.56..6.96 rows=1 width=82) (actual time=0.172..0.172 rows=0 loops=19692)" (2)->Bitmap Heap Scan on nfe_empresa ng (cost=754.02..35223.76 rows=20080 width=42) (actual time=181.835..2081.888 rows=19692 loops=1)" (3)->Nested Loop (cost=754.57..175161.36 rows=45 width=124) (actual time=3691.302..5502.554 rows=2878 loops=1)" (4)->Index Scan using pk_nfe on nfe n (cost=0.56..6.85 rows=1 width=96) (actual time=0.043..0.043 rows=1 loops=2878)" (5)->Nested Loop (cost=755.13..175470.60 rows=21 width=220) (actual time=3691.387..5640.336 rows=2878 loops=1)" Seria necessário a query para identificar a causa dos loops. 2017-04-26 9:44 GMT-03:00 Jorge Loss JR <jorgelos...@gmail.com>: > Segue minha análise. Caso eu esteja errado, sintam-se à vontade para me > corrigir, assim eu aprendo junto: > > O join da tabela "nfe_empresa ng"(2) com a tabela "nfe_ident ni"(1) > resulta em "2878 linhas"(3). > Para cada linha do resultado, é feito um "join" com "nfe n"(4) e (5) > identificador por loops=2878 > Depois com (ver Nested Loop) > nfe_emitente ne: Para cada de "n" linha do join é feito uma busca no > índice loops=2878 (creio que o problema esteja aqui, pois aumenta muito o > custo) > " -> Nested Loop (cost=755.68..175486.51 rows=10 width=204) > (actual time=3691.454..12259.435 rows=2878 loops=1)" > Depois com (ver Nested Loop) > nfe_destinatario nd: Para cada de "n" linha do join é feito uma busca no > índice loops=2878 > Depois com (ver Nested Loop) > nfe_transp nt: Para cada de "n" linha do join é feito uma busca no > índice loops=2878 > > Por último é feito join do resultado dos passos anteriores com o subplano > 9 (que não é tão custoso, pois não retorna nenhuma linha) > > > (1)->Index Scan using pk_nfe_ident on nfe_ident ni (cost=0.56..6.96 > rows=1 width=82) (actual time=0.172..0.172 rows=0 loops=19692)" > (2)->Bitmap Heap Scan on nfe_empresa ng (cost=754.02..35223.76 rows=20080 > width=42) (actual time=181.835..2081.888 rows=19692 loops=1)" > (3)->Nested Loop (cost=754.57..175161.36 rows=45 width=124) (actual > time=3691.302..5502.554 rows=2878 loops=1)" > (4)->Index Scan using pk_nfe on nfe n (cost=0.56..6.85 rows=1 width=96) > (actual time=0.043..0.043 rows=1 loops=2878)" > (5)->Nested Loop (cost=755.13..175470.60 rows=21 width=220) (actual > time=3691.387..5640.336 rows=2878 loops=1)" > > 2017-04-25 22:07 GMT-03:00 Alexsandro Haag <alexsandro.h...@gmail.com>: > >> >> Em 25/04/2017 21:10, Júlio César Martini escreveu: >> >>> >>> O que me chamou atenção ao fazer o EXPLAIN nesta SQL é que na lenta tem >>> um SORT que aparentemente é ele o causador, mas não entendi o pq visto que >>> não faço ORDER BY de nada (me desculpe se falei algum absurdo). >>> >> >> Me parece mais que o seq_scan seja o causador da lentidão. >> Voce tem um índice auxiliar para estas colunas? >> >> * Sort Key: ng.cnpj_emitente, ng.numero, ng.serie, ng.tpamb, ng.mod >> >> >> Seria legal postar as suas queries também... >> >> >> _______________________________________________ >> pgbr-geral mailing list >> pgbr-geral@listas.postgresql.org.br >> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >> > >
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
