Olá, 2009/12/4 Thiago Freitas <[email protected]>
> Exato, a mesma consulta com esta única diferença. Realmente, eu percebi > esta mensagem mas não sei o que devo fazer... > O André comentou de aumentar o work_mem. O valor padrão é 1 MB, sempre que você tem operações de ORDER BY e GROUP BY. Você pode fazer o seguinte teste: SET work_mem TO "10MB"; Sua consulta. E ver o resultado, ao fim você pode fazer SET work_mem TO DEFAULT; Ou ao deixar a sessão automaticamente o valor é retorno ao original visto que sua modificação foi na seção. O Guedes comentou do ANALYZE. Você já executou esta operação? > > 2009/12/4 Dickson S. Guedes <[email protected]> > > 2009/12/4 JotaComm <[email protected]>: >> > Olá, >> > >> > 2009/12/4 Thiago Freitas <[email protected]> >> >> >> >> Bom dia! >> >> >> >> Estou fazendo uma consulta e quando o valor de uma coluna é 1 o retorno >> é >> >> rápido (poucos registros). Quando o valor da coluna é 0 o retorno é >> lento >> >> (muitos registros). >> >> Será que eu poderia fazer alguma mudança com base no QUERY PLAN? >> >> >> >> >> >> QUERY PLAN >> >> >> >> >> -------------------------------------------------------------------------------------------------------------------------------------------------------- >> >> HashAggregate (cost=49764.02..49826.68 rows=2785 width=50) (actual >> >> time=282.839..282.986 rows=211 loops=1) >> >> -> Index Scan using "S1IP_I01" on stg1_nfe_item_proc item >> >> (cost=0.00..49207.14 rows=27844 width=50) (actual time=0.091..55.692 >> >> rows=97950 loops=1) >> >> Index Cond: ((("emit_cMun")::text = '3550308'::text) AND >> >> (("ide_tpNF")::text = '0'::text)) >> >> Total runtime: 283.059 ms >> >> (4 registros) >> >> >> >> QUERY PLAN >> >> >> >> >> ---------------------------------------------------------------------------------------------------------------------------- >> >> GroupAggregate (cost=114030.00..119682.56 rows=22839 width=50) >> (actual >> >> time=2116.395..3020.904 rows=13225 loops=1) >> >> -> Sort (cost=114030.00..114600.97 rows=228386 width=50) (actual >> >> time=2116.377..2717.973 rows=184488 loops=1) >> >> Sort Key: "seqAgrupamento", "prod_CFOP", "prod_NCM" >> >> Sort Method: external merge Disk: 12360kB >> >> -> Bitmap Heap Scan on stg1_nfe_item_proc item >> >> (cost=5201.58..78085.37 rows=228386 width=50) (actual >> time=37.296..146.287 >> >> rows=184488 loops=1) >> >> Recheck Cond: ((("emit_cMun")::text = '3550308'::text) >> AND >> >> (("ide_tpNF")::text = '1'::text)) >> >> -> Bitmap Index Scan on "S1IP_I01" (cost=0.00..5144.49 >> >> rows=228386 width=0) (actual time=36.352..36.352 rows=184488 loops=1) >> >> Index Cond: ((("emit_cMun")::text = >> '3550308'::text) >> >> AND (("ide_tpNF")::text = '1'::text)) >> >> Total runtime: 3026.089 ms >> >> (9 registros) >> >> >> >> Obrigado! >> > >> > Esta sua coluna está indexada? Índice parcial? >> >> >> É a mesma consulta em ambos os casos com a diferença do parâmetro >> "ide_tpNF"? >> >> Você percebeu que a segunda está "swapando" (Sort Method: external >> merge Disk: 12360kB)? >> >> Veja que as estimativas estão um pouco estranhas também, rodou ANALYZE? >> >> []s >> Dickson S. Guedes >> mail/xmpp: [email protected] - skype: guediz >> http://guedesoft.net - http://www.postgresql.org.br >> _______________________________________________ >> pgbr-geral mailing list >> [email protected] >> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >> > > > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > > []s -- JotaComm http://jotacomm.wordpress.com
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
