[pgbr-geral] RES: RES: RES: RES: Problemas de desempenho

[Márcio A . Sepp]

 

Márcio, realmente, o upper e o coalesce impedem o uso do índice no campo. 
Sugiro você criar um índice com o campo já maiúsculo e remover o coalesce, já 
que me parece não ter muito uso substituir os nulos por '%' (provavelmente essa 
cláusula não tem efeito algum na sua consulta, a menos que ela seja gerada 
dinamicamente). Faça o mesmo para os demais campos e rode um analyze novamente, 
só para garantir. :)

 

CREATE INDEX ON emitente ((upper(nm_emitentecompleto)));

 

Para resolver a cláusula em parc.vlr_valor, sugiro você isolar os valores nulos 
em uma condição própria, algo como:

 

(parc.vl_valor between 0 and 9 or parc.vl_valor is null)

 

 

No parc.vl_valor eu setei para not null e, tirando o coalesce ficou muito bom.

Agora criei o índice na tabela uni_emitente (cfe o comando que vc passou 
acima), rodei analyze no banco todo, deixei a linha assim: 
emitente.nm_emitentecompleto like '%CONSUMIDOR%' and

e não resolveu. Se comento esta linha fica bala.

Pra ter uma idéia tá rodando a 20 minutos e não vai. Não consigo nem tirar o 
analyze pra enviar.

 

 

Agora, apenas para entendimento:

1) Onde diz no explain analyze que o problema era com estas duas linhas? (como 
disse, sou bem leigo nisso e to tentando aprender - Talvez nem tem como saber 
por ele...);

 

2) Sabem o pq dele rodar bem na 9.0 e lento na 9.4 e 9.5? 

Passei por alto no relnotes, mas não encontrei nada... (talvez tenha visto, mas 
como não manjo muito, posso não ter entendido)

 

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] RES: RES: RES: Problemas de desempenho

[Michel Luiz Milezzi]

Márcio, realmente, o upper e o coalesce impedem o uso do índice no campo.
Sugiro você criar um índice com o campo já maiúsculo e remover o coalesce,
já que me parece não ter muito uso substituir os nulos por '%'
(provavelmente essa cláusula não tem efeito algum na sua consulta, a menos
que ela seja gerada dinamicamente). Faça o mesmo para os demais campos e
rode um analyze novamente, só para garantir. :)

CREATE INDEX ON emitente ((upper(nm_emitentecompleto)));


Para resolver a cláusula em parc.vlr_valor, sugiro você isolar os valores
nulos em uma condição própria, algo como:

(parc.vl_valor between 0 and 9* or parc.vl_valor is null*)





Em 4 de abril de 2016 21:07, Márcio A. Sepp 
escreveu:

>
>
> 2016-04-04 17:47 GMT-03:00 Márcio A. Sepp :
>
> > Bom dia,
> >
> >
> > Atualizei um servidor que estava utilizando a versão 9.0 para a 9.4.7
> > e após atualização esta query passou a ficar extremamente lenta.
> >.
> >
> >
> > Pelo que estou entendendo o problema está no fin_receber_cnt. Mas não
> > to achando o furo.
> > Observem que na versão 9.0 estava funcionando de forma satisfatoria.
> >
>
>
> Atualize as estatísticas com o comando ANALYZE.
> http://www.postgresql.org/docs/9.4/interactive/sql-analyze.html
>
> Por favor, me explique como vc chegou a esta conclusão? diz algo aí que as
> estatísticas estão desatualizadas? (eu não manjo muito da saída do analyze
> e to me batendo nisso a horas).
> Mas eu havia feito todas as manutenções antes de enviar a saída do analyze
> e inclusive peguei o banco e subi numa máquina minha e continua na mesma
> lentidão.
>
> Talvez precise que eu envie mais alguma informação pra ajudar?
>
>
>
> O tempo estimado e o tempo real são muito divergentes, talvez por isso a
> sugestão do analyze, e também porque é praxe que as estatísticas estejam
> desatualizadas.
>
> Utilize [1] para facilitar a visualização, se possível, e cole a URL do
> seu explain.
>
> O problema parece começar em alguns loops e filtros sem índices, mas será
> melhor de visualizar após nos passar o link do explain.
>
> Eu tentei utilizando o resultado que você passou e não deu certo.
>
>
>
> [1] - http://explain.depesz.com/
>
>
>
> Rodei analyze (no banco que subi aqui) agora.
>
>
>
>
>
> http://explain.depesz.com/s/b55L
>
>
>
>
>
>
>
> Fazendo testes, percebi que o problema está nestas duas linhas aqui:
>
>   upper(coalesce(emitente.nm_emitentecompleto, '%')) like
> upper('%consumidor%') and
>
>   coalesce(parc.vl_valor, 0) between coalesce(0, 0) and
> coalesce(99.99, 9) and
>
>
>
> Comentando elas o retorno fica em 2 ms, o que é aceitável.
>
> Tentei retirar os operadores upper e coalesce destas linhas, mas ainda
> continua lento. Fui até as tabelas emitente e parc e criei indices nestas
> colunas, mas tbm não resolveu. Se alguém puder ajudar, agradeço muito.
>
>
>
> ___
> 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

[pgbr-geral] RES: RES: RES: Problemas de desempenho

[Márcio A . Sepp]

 

2016-04-04 17:47 GMT-03:00 Márcio A. Sepp :

> Bom dia,
>
>
> Atualizei um servidor que estava utilizando a versão 9.0 para a 9.4.7
> e após atualização esta query passou a ficar extremamente lenta.
>.
>
>
> Pelo que estou entendendo o problema está no fin_receber_cnt. Mas não
> to achando o furo.
> Observem que na versão 9.0 estava funcionando de forma satisfatoria.
>


Atualize as estatísticas com o comando ANALYZE.
http://www.postgresql.org/docs/9.4/interactive/sql-analyze.html

Por favor, me explique como vc chegou a esta conclusão? diz algo aí que as 
estatísticas estão desatualizadas? (eu não manjo muito da saída do analyze e to 
me batendo nisso a horas).
Mas eu havia feito todas as manutenções antes de enviar a saída do analyze e 
inclusive peguei o banco e subi numa máquina minha e continua na mesma lentidão.

Talvez precise que eu envie mais alguma informação pra ajudar?

 

O tempo estimado e o tempo real são muito divergentes, talvez por isso a 
sugestão do analyze, e também porque é praxe que as estatísticas estejam 
desatualizadas.

Utilize [1] para facilitar a visualização, se possível, e cole a URL do seu 
explain.

O problema parece começar em alguns loops e filtros sem índices, mas será 
melhor de visualizar após nos passar o link do explain.

Eu tentei utilizando o resultado que você passou e não deu certo.

 

[1] - http://explain.depesz.com/ 

 

Rodei analyze (no banco que subi aqui) agora. 

 

 

http://explain.depesz.com/s/b55L

 

 

 

Fazendo testes, percebi que o problema está nestas duas linhas aqui:

  upper(coalesce(emitente.nm_emitentecompleto, '%')) like 
upper('%consumidor%') and 

  coalesce(parc.vl_valor, 0) between coalesce(0, 0) and coalesce(99.99, 
9) and

 

Comentando elas o retorno fica em 2 ms, o que é aceitável.

Tentei retirar os operadores upper e coalesce destas linhas, mas ainda continua 
lento. Fui até as tabelas emitente e parc e criei indices nestas colunas, mas 
tbm não resolveu. Se alguém puder ajudar, agradeço muito.

 

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] RES: RES: Problemas de desempenho

[Márcio A . Sepp]

 

2016-04-04 17:47 GMT-03:00 Márcio A. Sepp :

> Bom dia,
>
>
> Atualizei um servidor que estava utilizando a versão 9.0 para a 9.4.7
> e após atualização esta query passou a ficar extremamente lenta.
>.
>
>
> Pelo que estou entendendo o problema está no fin_receber_cnt. Mas não
> to achando o furo.
> Observem que na versão 9.0 estava funcionando de forma satisfatoria.
>


Atualize as estatísticas com o comando ANALYZE.
http://www.postgresql.org/docs/9.4/interactive/sql-analyze.html



Por favor, me explique como vc chegou a esta conclusão? diz algo aí que as 
estatísticas estão desatualizadas? (eu não manjo muito da saída do analyze e to 
me batendo nisso a horas).
Mas eu havia feito todas as manutenções antes de enviar a saída do analyze e 
inclusive peguei o banco e subi numa máquina minha e continua na mesma lentidão.

Talvez precise que eu envie mais alguma informação pra ajudar?

 

O tempo estimado e o tempo real são muito divergentes, talvez por isso a 
sugestão do analyze, e também porque é praxe que as estatísticas estejam 
desatualizadas.

Utilize [1] para facilitar a visualização, se possível, e cole a URL do seu 
explain.

O problema parece começar em alguns loops e filtros sem índices, mas será 
melhor de visualizar após nos passar o link do explain.

Eu tentei utilizando o resultado que você passou e não deu certo.

 

[1] - http://explain.depesz.com/ 

 

Rodei analyze (no banco que subi aqui) agora. 

 

 

http://explain.depesz.com/s/b55L

 

 

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] RES: Problemas de desempenho

[Rafael Fialho]

2016-04-04 17:47 GMT-03:00 Márcio A. Sepp :

> > Bom dia,
> >
> >
> > Atualizei um servidor que estava utilizando a versão 9.0 para a 9.4.7
> > e após atualização esta query passou a ficar extremamente lenta.
> >.
> >
> >
> > Pelo que estou entendendo o problema está no fin_receber_cnt. Mas não
> > to achando o furo.
> > Observem que na versão 9.0 estava funcionando de forma satisfatoria.
> >
>
>
> Atualize as estatísticas com o comando ANALYZE.
> http://www.postgresql.org/docs/9.4/interactive/sql-analyze.html
>
>
> Por favor, me explique como vc chegou a esta conclusão? diz algo aí que as
> estatísticas estão desatualizadas? (eu não manjo muito da saída do analyze
> e to me batendo nisso a horas).
> Mas eu havia feito todas as manutenções antes de enviar a saída do analyze
> e inclusive peguei o banco e subi numa máquina minha e continua na mesma
> lentidão.
>
> Talvez precise que eu envie mais alguma informação pra ajudar?


O tempo estimado e o tempo real são muito divergentes, talvez por isso a
sugestão do analyze, e também porque é praxe que as estatísticas estejam
desatualizadas.
Utilize [1] para facilitar a visualização, se possível, e cole a URL do seu
explain.
O problema parece começar em alguns loops e filtros sem índices, mas será
melhor de visualizar após nos passar o link do explain.
Eu tentei utilizando o resultado que você passou e não deu certo.

[1] - http://explain.depesz.com/

[]'s
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] RES: Problemas de desempenho

[Michel Luiz Milezzi]

Acredito que o amigo sugeriu o analyze por ser um procedimento padrão após
restore, conforme menciona a documentação:

"After restoring a backup, it is wise to run ANALYZE
 on each
database so the query optimizer has useful statistics"
http://www.postgresql.org/docs/9.4/static/backup-dump.html#BACKUP-DUMP-RESTORE

De qualquer forma, você pode verificar as estatísticas das tabelas pela
view pg_stat_user_tables (ou por sua: variante: pg_stat_all_tables).

Abraço!



2016-04-04 17:47 GMT-03:00 Márcio A. Sepp :

> > Bom dia,
> >
> >
> > Atualizei um servidor que estava utilizando a versão 9.0 para a 9.4.7
> > e após atualização esta query passou a ficar extremamente lenta.
> >
> > SQL:
> > select movto_lote.nr_dcto
> > from fin_receber_parc parc
> > inner join fin_receber receber on (receber.cd_movto = parc.cd_movto_rec
> and
> >receber.cd_serie_lcto =
> > parc.cd_serie_lcto)
> > inner join fin_receber_cnt cnt on (cnt.cd_movto_rec= receber.cd_movto and
> >
> > cnt.cd_serie_lcto=receber.cd_serie_lcto)
> > inner join cnt_movto movto on (cnt.cd_movto=movto.cd_movto and
> >movto.cd_serie_lcto=cnt.cd_serie_lcto)
> > inner join cnt_movto_lote movto_lote on (movto_lote.cd_movto =
> > movto.cd_movto_lote and
> >  movto_lote.cd_serie_lcto =
> > movto.cd_serie_lcto)
> > inner join cnt_competencia competencia on (competencia.cd_competencia
> > =
> > movto_lote.cd_competencia)
> > inner join uni_emitente emitente on (emitente.cd_emitente =
> > receber.cd_devedor)
> > inner join fin_especie especie on (especie.cd_especie =
> > parc.cd_especie ) where upper(coalesce(movto_lote.ds_historico, '%'))
> like upper('%%') and
> >   upper(coalesce(movto_lote.nr_dcto, '%')) like upper('%%') and
> >   upper(coalesce(competencia.nm_competencia, '%')) like upper('%%')
> and
> >   upper(coalesce(emitente.nm_emitentecompleto, '%')) like
> > upper('%consumidor%') and
> >   coalesce(parc.vl_valor, 0) between coalesce(0, 0) and
> > coalesce(99.99, 9) and
> >   coalesce(receber.cd_devedor, 0) between coalesce(0, 0) and
> > coalesce(9, 9) and
> >   movto_lote.dt_movto between ('01/01/2000') and ('01/03/') and
> >   parc.dt_vcto between ('01/01/2000') and ('31/12/') and
> >   parc.st_quitado = false and
> >   movto_lote.cd_estabelecimento=1
> > order by parc.dt_vcto desc
> >
> >
> > Saída do Explain Analyze:
> > "Sort  (cost=4779.91..4779.91 rows=1 width=16) (actual
> > time=128286.342..128286.342 rows=6 loops=1)"
> > "  Sort Key: parc.dt_vcto DESC"
> > "  Sort Method: quicksort  Memory: 25kB"
> > "  ->  Nested Loop  (cost=1.96..4779.90 rows=1 width=16) (actual
> > time=126064.707..128286.279 rows=6 loops=1)"
> > "Join Filter: (parc.cd_especie = especie.cd_especie)"
> > "Rows Removed by Join Filter: 36"
> > "->  Nested Loop  (cost=1.96..4778.74 rows=1 width=18) (actual
> > time=126064.672..128286.198 rows=6 loops=1)"
> > "  ->  Nested Loop  (cost=1.68..4777.55 rows=1 width=22)
> (actual
> > time=64031.477..128247.981 rows=3189 loops=1)"
> > "Join Filter: (movto_lote.cd_competencia =
> > competencia.cd_competencia)"
> > "Rows Removed by Join Filter: 15945"
> > "->  Nested Loop  (cost=1.68..4776.37 rows=1
> width=26)
> > (actual time=64031.432..128164.285 rows=3189 loops=1)"
> > "  Join Filter: (receber.cd_serie_lcto =
> > movto_lote.cd_serie_lcto)"
> > "  ->  Nested Loop  (cost=1.26..4775.86 rows=1
> > width=26) (actual time=0.085..128005.877 rows=6277 loops=1)"
> > "Join Filter: (receber.cd_serie_lcto =
> > movto.cd_serie_lcto)"
> > "->  Nested Loop  (cost=0.83..4774.95
> rows=1
> > width=24) (actual time=0.078..127775.182 rows=6277 loops=1)"
> > "  ->  Nested Loop
> (cost=0.42..3012.16
> > rows=1 width=30) (actual time=0.067..214.384 rows=6318 loops=1)"
> > "->  Seq Scan on
> > fin_receber_parc parc  (cost=0.00..2745.68 rows=32 width=16) (actual
> > time=0.052..91.802 rows=6318 loops=1)"
> > "  Filter: ((NOT
> st_quitado)
> > AND (COALESCE(vl_valor, '0'::numeric) >= '0'::numeric) AND
> > (COALESCE(vl_valor, '0'::numeric) <= 99.99) AND (dt_vcto >=
> > '2000-01-01'::date) AND (dt_vcto <= '-12-31'::date))"
> > "  Rows Removed by
> Filter:
> > 81216"
> > "->  Index Scan using
> > "pk-fin_receber-geral" on fin_receber receber  (cost=0.42..8.32 rows=1
> > width=14) (actual time=0.013..0.014 rows=1 loops=6318)"
> > " 

[pgbr-geral] RES: Problemas de desempenho

[Márcio A . Sepp]

> Bom dia,
>
>
> Atualizei um servidor que estava utilizando a versão 9.0 para a 9.4.7 
> e após atualização esta query passou a ficar extremamente lenta.
>
> SQL:
> select movto_lote.nr_dcto
> from fin_receber_parc parc
> inner join fin_receber receber on (receber.cd_movto = parc.cd_movto_rec and
>receber.cd_serie_lcto =
> parc.cd_serie_lcto)
> inner join fin_receber_cnt cnt on (cnt.cd_movto_rec= receber.cd_movto and
>
> cnt.cd_serie_lcto=receber.cd_serie_lcto)
> inner join cnt_movto movto on (cnt.cd_movto=movto.cd_movto and
>movto.cd_serie_lcto=cnt.cd_serie_lcto)
> inner join cnt_movto_lote movto_lote on (movto_lote.cd_movto = 
> movto.cd_movto_lote and
>  movto_lote.cd_serie_lcto =
> movto.cd_serie_lcto)
> inner join cnt_competencia competencia on (competencia.cd_competencia 
> =
> movto_lote.cd_competencia)
> inner join uni_emitente emitente on (emitente.cd_emitente =
> receber.cd_devedor)
> inner join fin_especie especie on (especie.cd_especie = 
> parc.cd_especie ) where upper(coalesce(movto_lote.ds_historico, '%')) like 
> upper('%%') and
>   upper(coalesce(movto_lote.nr_dcto, '%')) like upper('%%') and
>   upper(coalesce(competencia.nm_competencia, '%')) like upper('%%') and
>   upper(coalesce(emitente.nm_emitentecompleto, '%')) like
> upper('%consumidor%') and
>   coalesce(parc.vl_valor, 0) between coalesce(0, 0) and 
> coalesce(99.99, 9) and
>   coalesce(receber.cd_devedor, 0) between coalesce(0, 0) and 
> coalesce(9, 9) and
>   movto_lote.dt_movto between ('01/01/2000') and ('01/03/') and
>   parc.dt_vcto between ('01/01/2000') and ('31/12/') and
>   parc.st_quitado = false and
>   movto_lote.cd_estabelecimento=1
> order by parc.dt_vcto desc
>
>
> Saída do Explain Analyze:
> "Sort  (cost=4779.91..4779.91 rows=1 width=16) (actual
> time=128286.342..128286.342 rows=6 loops=1)"
> "  Sort Key: parc.dt_vcto DESC"
> "  Sort Method: quicksort  Memory: 25kB"
> "  ->  Nested Loop  (cost=1.96..4779.90 rows=1 width=16) (actual
> time=126064.707..128286.279 rows=6 loops=1)"
> "Join Filter: (parc.cd_especie = especie.cd_especie)"
> "Rows Removed by Join Filter: 36"
> "->  Nested Loop  (cost=1.96..4778.74 rows=1 width=18) (actual
> time=126064.672..128286.198 rows=6 loops=1)"
> "  ->  Nested Loop  (cost=1.68..4777.55 rows=1 width=22) (actual
> time=64031.477..128247.981 rows=3189 loops=1)"
> "Join Filter: (movto_lote.cd_competencia =
> competencia.cd_competencia)"
> "Rows Removed by Join Filter: 15945"
> "->  Nested Loop  (cost=1.68..4776.37 rows=1 width=26)
> (actual time=64031.432..128164.285 rows=3189 loops=1)"
> "  Join Filter: (receber.cd_serie_lcto =
> movto_lote.cd_serie_lcto)"
> "  ->  Nested Loop  (cost=1.26..4775.86 rows=1
> width=26) (actual time=0.085..128005.877 rows=6277 loops=1)"
> "Join Filter: (receber.cd_serie_lcto =
> movto.cd_serie_lcto)"
> "->  Nested Loop  (cost=0.83..4774.95 rows=1
> width=24) (actual time=0.078..127775.182 rows=6277 loops=1)"
> "  ->  Nested Loop  (cost=0.42..3012.16
> rows=1 width=30) (actual time=0.067..214.384 rows=6318 loops=1)"
> "->  Seq Scan on
> fin_receber_parc parc  (cost=0.00..2745.68 rows=32 width=16) (actual
> time=0.052..91.802 rows=6318 loops=1)"
> "  Filter: ((NOT st_quitado)
> AND (COALESCE(vl_valor, '0'::numeric) >= '0'::numeric) AND 
> (COALESCE(vl_valor, '0'::numeric) <= 99.99) AND (dt_vcto >=
> '2000-01-01'::date) AND (dt_vcto <= '-12-31'::date))"
> "  Rows Removed by Filter:
> 81216"
> "->  Index Scan using
> "pk-fin_receber-geral" on fin_receber receber  (cost=0.42..8.32 rows=1
> width=14) (actual time=0.013..0.014 rows=1 loops=6318)"
> "  Index Cond: ((cd_movto =
> parc.cd_movto_rec) AND (cd_serie_lcto = parc.cd_serie_lcto))"
> "  Filter:
> ((COALESCE(cd_devedor, 0) >= 0) AND (COALESCE(cd_devedor, 0) <= 9))"
> "  ->  Index Scan using
> "pk-fin_receber_cnt-cd_movto-cd_serie_lcto" on fin_receber_cnt cnt
> (cost=0.42..1762.78 rows=1 width=18) (actual time=7.918..20.187 rows=1 
> loops=6318)"
> "Index Cond: (cd_serie_lcto =
> receber.cd_serie_lcto)"
> "Filter: (receber.cd_movto =
> cd_movto_rec)"
> "Rows Removed by Filter: 87707"
> "  

Re: [pgbr-geral] Problemas de desempenho

[Osvaldo Kussama]

2016-04-04 17:15 GMT-03:00, Márcio A. Sepp :
>
> Bom dia,
>
>
> Atualizei um servidor que estava utilizando a versão 9.0 para a 9.4.7 e após
> atualização esta query passou a ficar extremamente lenta.
>
> SQL:
> select movto_lote.nr_dcto
> from fin_receber_parc parc
> inner join fin_receber receber on (receber.cd_movto = parc.cd_movto_rec and
>receber.cd_serie_lcto =
> parc.cd_serie_lcto)
> inner join fin_receber_cnt cnt on (cnt.cd_movto_rec= receber.cd_movto and
>cnt.cd_serie_lcto=receber.cd_serie_lcto)
> inner join cnt_movto movto on (cnt.cd_movto=movto.cd_movto and
>movto.cd_serie_lcto=cnt.cd_serie_lcto)
> inner join cnt_movto_lote movto_lote on (movto_lote.cd_movto =
> movto.cd_movto_lote and
>  movto_lote.cd_serie_lcto =
> movto.cd_serie_lcto)
> inner join cnt_competencia competencia on (competencia.cd_competencia =
> movto_lote.cd_competencia)
> inner join uni_emitente emitente on (emitente.cd_emitente =
> receber.cd_devedor)
> inner join fin_especie especie on (especie.cd_especie = parc.cd_especie )
> where upper(coalesce(movto_lote.ds_historico, '%')) like upper('%%') and
>   upper(coalesce(movto_lote.nr_dcto, '%')) like upper('%%') and
>   upper(coalesce(competencia.nm_competencia, '%')) like upper('%%') and
>   upper(coalesce(emitente.nm_emitentecompleto, '%')) like
> upper('%consumidor%') and
>   coalesce(parc.vl_valor, 0) between coalesce(0, 0) and
> coalesce(99.99, 9) and
>   coalesce(receber.cd_devedor, 0) between coalesce(0, 0) and
> coalesce(9, 9) and
>   movto_lote.dt_movto between ('01/01/2000') and ('01/03/') and
>   parc.dt_vcto between ('01/01/2000') and ('31/12/') and
>   parc.st_quitado = false and
>   movto_lote.cd_estabelecimento=1
> order by parc.dt_vcto desc
>
>
> Saída do Explain Analyze:
> "Sort  (cost=4779.91..4779.91 rows=1 width=16) (actual
> time=128286.342..128286.342 rows=6 loops=1)"
> "  Sort Key: parc.dt_vcto DESC"
> "  Sort Method: quicksort  Memory: 25kB"
> "  ->  Nested Loop  (cost=1.96..4779.90 rows=1 width=16) (actual
> time=126064.707..128286.279 rows=6 loops=1)"
> "Join Filter: (parc.cd_especie = especie.cd_especie)"
> "Rows Removed by Join Filter: 36"
> "->  Nested Loop  (cost=1.96..4778.74 rows=1 width=18) (actual
> time=126064.672..128286.198 rows=6 loops=1)"
> "  ->  Nested Loop  (cost=1.68..4777.55 rows=1 width=22) (actual
> time=64031.477..128247.981 rows=3189 loops=1)"
> "Join Filter: (movto_lote.cd_competencia =
> competencia.cd_competencia)"
> "Rows Removed by Join Filter: 15945"
> "->  Nested Loop  (cost=1.68..4776.37 rows=1 width=26)
> (actual time=64031.432..128164.285 rows=3189 loops=1)"
> "  Join Filter: (receber.cd_serie_lcto =
> movto_lote.cd_serie_lcto)"
> "  ->  Nested Loop  (cost=1.26..4775.86 rows=1
> width=26) (actual time=0.085..128005.877 rows=6277 loops=1)"
> "Join Filter: (receber.cd_serie_lcto =
> movto.cd_serie_lcto)"
> "->  Nested Loop  (cost=0.83..4774.95 rows=1
> width=24) (actual time=0.078..127775.182 rows=6277 loops=1)"
> "  ->  Nested Loop  (cost=0.42..3012.16
> rows=1 width=30) (actual time=0.067..214.384 rows=6318 loops=1)"
> "->  Seq Scan on
> fin_receber_parc parc  (cost=0.00..2745.68 rows=32 width=16) (actual
> time=0.052..91.802 rows=6318 loops=1)"
> "  Filter: ((NOT st_quitado)
> AND (COALESCE(vl_valor, '0'::numeric) >= '0'::numeric) AND
> (COALESCE(vl_valor, '0'::numeric) <= 99.99) AND (dt_vcto >=
> '2000-01-01'::date) AND (dt_vcto <= '-12-31'::date))"
> "  Rows Removed by Filter:
> 81216"
> "->  Index Scan using
> "pk-fin_receber-geral" on fin_receber receber  (cost=0.42..8.32 rows=1
> width=14) (actual time=0.013..0.014 rows=1 loops=6318)"
> "  Index Cond: ((cd_movto =
> parc.cd_movto_rec) AND (cd_serie_lcto = parc.cd_serie_lcto))"
> "  Filter:
> ((COALESCE(cd_devedor, 0) >= 0) AND (COALESCE(cd_devedor, 0) <= 9))"
> "  ->  Index Scan using
> "pk-fin_receber_cnt-cd_movto-cd_serie_lcto" on fin_receber_cnt cnt
> (cost=0.42..1762.78 rows=1 width=18) (actual time=7.918..20.187 rows=1
> loops=6318)"
> "Index Cond: (cd_serie_lcto =
> receber.cd_serie_lcto)"
> "Filter: (receber.cd_movto =
> cd_movto_rec)"
> "   

[pgbr-geral] Problemas de desempenho

[Márcio A . Sepp]

Bom dia,


Atualizei um servidor que estava utilizando a versão 9.0 para a 9.4.7 e após
atualização esta query passou a ficar extremamente lenta.

SQL:
select movto_lote.nr_dcto
from fin_receber_parc parc 
inner join fin_receber receber on (receber.cd_movto = parc.cd_movto_rec and 
   receber.cd_serie_lcto =
parc.cd_serie_lcto) 
inner join fin_receber_cnt cnt on (cnt.cd_movto_rec= receber.cd_movto and 
   cnt.cd_serie_lcto=receber.cd_serie_lcto) 
inner join cnt_movto movto on (cnt.cd_movto=movto.cd_movto and 
   movto.cd_serie_lcto=cnt.cd_serie_lcto) 
inner join cnt_movto_lote movto_lote on (movto_lote.cd_movto =
movto.cd_movto_lote and 
 movto_lote.cd_serie_lcto =
movto.cd_serie_lcto) 
inner join cnt_competencia competencia on (competencia.cd_competencia =
movto_lote.cd_competencia) 
inner join uni_emitente emitente on (emitente.cd_emitente =
receber.cd_devedor) 
inner join fin_especie especie on (especie.cd_especie = parc.cd_especie ) 
where upper(coalesce(movto_lote.ds_historico, '%')) like upper('%%') and 
  upper(coalesce(movto_lote.nr_dcto, '%')) like upper('%%') and 
  upper(coalesce(competencia.nm_competencia, '%')) like upper('%%') and 
  upper(coalesce(emitente.nm_emitentecompleto, '%')) like
upper('%consumidor%') and 
  coalesce(parc.vl_valor, 0) between coalesce(0, 0) and
coalesce(99.99, 9) and 
  coalesce(receber.cd_devedor, 0) between coalesce(0, 0) and
coalesce(9, 9) and 
  movto_lote.dt_movto between ('01/01/2000') and ('01/03/') and 
  parc.dt_vcto between ('01/01/2000') and ('31/12/') and 
  parc.st_quitado = false and 
  movto_lote.cd_estabelecimento=1 
order by parc.dt_vcto desc


Saída do Explain Analyze:
"Sort  (cost=4779.91..4779.91 rows=1 width=16) (actual
time=128286.342..128286.342 rows=6 loops=1)"
"  Sort Key: parc.dt_vcto DESC"
"  Sort Method: quicksort  Memory: 25kB"
"  ->  Nested Loop  (cost=1.96..4779.90 rows=1 width=16) (actual
time=126064.707..128286.279 rows=6 loops=1)"
"Join Filter: (parc.cd_especie = especie.cd_especie)"
"Rows Removed by Join Filter: 36"
"->  Nested Loop  (cost=1.96..4778.74 rows=1 width=18) (actual
time=126064.672..128286.198 rows=6 loops=1)"
"  ->  Nested Loop  (cost=1.68..4777.55 rows=1 width=22) (actual
time=64031.477..128247.981 rows=3189 loops=1)"
"Join Filter: (movto_lote.cd_competencia =
competencia.cd_competencia)"
"Rows Removed by Join Filter: 15945"
"->  Nested Loop  (cost=1.68..4776.37 rows=1 width=26)
(actual time=64031.432..128164.285 rows=3189 loops=1)"
"  Join Filter: (receber.cd_serie_lcto =
movto_lote.cd_serie_lcto)"
"  ->  Nested Loop  (cost=1.26..4775.86 rows=1
width=26) (actual time=0.085..128005.877 rows=6277 loops=1)"
"Join Filter: (receber.cd_serie_lcto =
movto.cd_serie_lcto)"
"->  Nested Loop  (cost=0.83..4774.95 rows=1
width=24) (actual time=0.078..127775.182 rows=6277 loops=1)"
"  ->  Nested Loop  (cost=0.42..3012.16
rows=1 width=30) (actual time=0.067..214.384 rows=6318 loops=1)"
"->  Seq Scan on
fin_receber_parc parc  (cost=0.00..2745.68 rows=32 width=16) (actual
time=0.052..91.802 rows=6318 loops=1)"
"  Filter: ((NOT st_quitado)
AND (COALESCE(vl_valor, '0'::numeric) >= '0'::numeric) AND
(COALESCE(vl_valor, '0'::numeric) <= 99.99) AND (dt_vcto >=
'2000-01-01'::date) AND (dt_vcto <= '-12-31'::date))"
"  Rows Removed by Filter:
81216"
"->  Index Scan using
"pk-fin_receber-geral" on fin_receber receber  (cost=0.42..8.32 rows=1
width=14) (actual time=0.013..0.014 rows=1 loops=6318)"
"  Index Cond: ((cd_movto =
parc.cd_movto_rec) AND (cd_serie_lcto = parc.cd_serie_lcto))"
"  Filter:
((COALESCE(cd_devedor, 0) >= 0) AND (COALESCE(cd_devedor, 0) <= 9))"
"  ->  Index Scan using
"pk-fin_receber_cnt-cd_movto-cd_serie_lcto" on fin_receber_cnt cnt
(cost=0.42..1762.78 rows=1 width=18) (actual time=7.918..20.187 rows=1
loops=6318)"
"Index Cond: (cd_serie_lcto =
receber.cd_serie_lcto)"
"Filter: (receber.cd_movto =
cd_movto_rec)"
"Rows Removed by Filter: 87707"
"->  Index Scan using
"pk-cnt_movto-cd_movto-cd_serie_lcto" on cnt_movto movto  (cost=0.42..0.90
rows=1 width=18) (actual time=0.031..0.031 rows=1 

Re: [pgbr-geral] pg_activity em Amazon RDS

[Cleiton Luiz Domazak]

2016-04-04 11:23 GMT-03:00 Sebastian Webber :

>
>
> Em 4 de abril de 2016 10:32, Cleiton Luiz Domazak <
> cleitondoma...@gmail.com> escreveu:
>
>> 
>>
>> Pois é, peguei a ultima versão, e o que dá pau é que dá com o RDS é a
>> database rdsadmin, que não existe role com acesso a ela, e com isso dá pau
>> no pg_activity.
>>
>
> Pelo que vi[1], ja tem um filtro no banco do rdsadmin. certeza que tu esta
> passando o parametro --rds?
>
> Posta o erro do pgsql e tb do pg_activity?
>
> [1]
> https://github.com/julmon/pg_activity/blob/6a65974dcc23e84aee36f2ec221711af365ee2ed/pgactivity/Data.py#L275
>

Fiz isso ai mesmo, criei uma issue, até pq se eu dou um --help o parâmetro
--rds nem aparece, deve ser algum bug.

Quando o pessoal lá responder posto aqui.

Vlw a ajuda pessoal.

>
>
>
> --
> Sebastian Webber
> http://swebber.me
>
> ___
> 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

Re: [pgbr-geral] VACUUM FULL ANALYZE VERBOSE

[Euler Taveira]

On 04-04-2016 09:26, Luiz Carlos L. Nogueira Jr. wrote:
> Não entendo o motivo desse comportamento.
> 
Você não apresentou o cenário do seu ambiente. Você possui replicação?
Quais os parâmetros diferente do padrão [1] da sua configuração?


[1] https://gist.github.com/eulerto/450501d8ef00404e665b46a2f2a6e8e2


-- 
   Euler Taveira   Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] pg_activity em Amazon RDS

[Sebastian Webber]

Em 4 de abril de 2016 10:32, Cleiton Luiz Domazak 
escreveu:

> 
>
> Pois é, peguei a ultima versão, e o que dá pau é que dá com o RDS é a
> database rdsadmin, que não existe role com acesso a ela, e com isso dá pau
> no pg_activity.
>

Pelo que vi[1], ja tem um filtro no banco do rdsadmin. certeza que tu esta
passando o parametro --rds?

Posta o erro do pgsql e tb do pg_activity?

[1]
https://github.com/julmon/pg_activity/blob/6a65974dcc23e84aee36f2ec221711af365ee2ed/pgactivity/Data.py#L275



-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] pg_activity em Amazon RDS

[Cleiton Luiz Domazak]

2016-04-02 0:11 GMT-03:00 Sebastian Webber :

>
>
> Em 2 de abril de 2016 00:07, Sebastian Webber 
> escreveu:
>
>
>> Pelo que vi no GitHub[1], o commit que foi implementado o suporte ao RDS
>> já foi feito merge. Certeza que está usando a versão mais recente?
>>
>> [1]
>> https://github.com/julmon/pg_activity/commit/759bad22d6def7bd265794ba57105bb33306a761
>>
>>
> O commit correto era esse:
>
>
> https://github.com/julmon/pg_activity/commit/8f46c2251ee5295e34754f8a2b87a606556d3af7
>
>

Pois é, peguei a ultima versão, e o que dá pau é que dá com o RDS é a
database rdsadmin, que não existe role com acesso a ela, e com isso dá pau
no pg_activity.

>
>
> --
> Sebastian Webber
> http://swebber.me
>
> ___
> 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

Re: [pgbr-geral] VACUUM FULL ANALYZE VERBOSE

[Luiz Carlos L. Nogueira Jr.]

Só consegui fazer o vacuum full depois de dar uma porrada de chekpoints na
base.
Mas com um checkpoint só não funcionou.
Não entendo o motivo desse comportamento.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral