Re: [pgbr-geral] quando usar vacuum full analyze

2016-09-02 Por tôpico Euler Taveira
On 01-09-2016 08:32, Luiz Henrique wrote:
> Segue anexo os planos da consulta. Obrigado pela ajuda
> 
Evite top-posting.

Faltou alguns dados: a consulta e os parâmetros [1]. Além disso, os
parâmetros são os mesmos nas duas máquinas? As versões são as mesmas
(digo, 9.1.23 e 9.1.23)? Você executou um ANALYZE em todas as tabelas da
consulta antes do EXPLAIN ANALYZE?

Em produção o que está levando bastante tempo é a junção abaixo (quase
70% do tempo).

[cortando partes do plano]

Hash Join  (actual time=2.298..90.849 rows=2027 loops=998)
  Hash Cond: (pf.id = p.id_pessoa)
  ->  Seq Scan on pessoa_fisica pf  (actual time=0.003..27.918
rows=303774 loops=998)
  ->  Hash (actual time=4.164..4.164 rows=3447 loops=1)
Buckets: 1024  Batches: 1  Memory Usage: 367kB
->  Seq Scan on parceiro p  (actual time=0.006..2.956 rows=3447
loops=1)

Há índices em pf.id e p.id_pessoa?

O mesmo ocorre com outra parte da consulta só que em pessoa_juridica.


-- 
   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] quando usar vacuum full analyze

2016-09-01 Por tôpico Guimarães Faria Corcete DUTRA , Leandro
2016-09-01 8:32 GMT-03:00 Luiz Henrique :
>
> Segue anexo os planos da consulta. Obrigado pela ajuda

Por favor prefira colocar informações em texto simples no corpo da
mensagem, facilita para todos.


-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191  gTalk: xmpp:leand...@jabber.org
+55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803
BRAZIL GMT−3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] quando usar vacuum full analyze

2016-09-01 Por tôpico Luiz Henrique
Euler,

Segue anexo os planos da consulta. Obrigado pela ajuda



Em 31 de agosto de 2016 22:21, Euler Taveira 
escreveu:

> On 31-08-2016 20:22, Luiz Henrique wrote:
> > Estou com problema de lentidão em uma determinada consulta no banco de
> > produção (centos linux postgresql 9.1). Tempo de 1 minuto em produção.
> > No ambiente de homologação leva cerca de 3s. O banco de produção é
> > copiado diariamente para homologação (em homol eu faço : dropdb,
> > createdb e pg_restore). Ambientes prod e homol praticamente iguais.
> > Pergunta :
> >
> > o vacuum full analyze pode resolver meu problema ?
> >
> Sim. É como matar uma mosca com uma 12.
>
> > quando usar vacuum full analyze ?
> >
> (quase) nunca. Só em casos extremos de inchaço (não sei se esse é o seu
> problema já que não apresentou informações).
>
> > alguma dica ou pista de como identificar a causa ?
> >
> Comece por mostrar os planos da consulta na produção e na homologação.
>
>
> --
>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




-- 
Atenciosamente,

Luiz Henrique

“A coruja de Minerva alça seu vôo somente com o início do crepúsculo”.
Friedrich Hegel
Pessoal,

A consulta é essa:

select distinct obt.id, obt.version , 
numero_obt as numeroObt, obt.data_cadastro as dataCadastroObt, 
data_tipo as dataTipo, valor_obt as valorObt, tob.nome as 
tipoOrdemBancariaNome, 
vps.nome as parceiro, fp.nome_razao_social as fornecedorParceiro, i.id as 
idInstrumento--, 
--max(acomp_gestor.data_cadastro) as ultimaAnaliseGestor, 
max(acomp_col.data_cadastro) as ultimaAnaliseColaborador 
from s2gpr_mcc.ordem_bancaria obt 
inner join s2gpr_mcc.instrumento i on i.id = obt.id_instrumento 
inner join s2gpr_mcc.tipo_ordem_bancaria tob on tob.id = 
obt.id_tipo_ordem_bancaria 
inner join s2gpr_mcc.vi_parceiro_situacao vps on vps.id = obt.id_parceiro 
left join s2gpr_mcc.fornecedor_parceiro fp on fp.id = 
obt.id_fornecedor_parceiro 
left join s2gpr_mcc.acompanhamento acomp_gestor on 
acomp_gestor.id_ordem_bancaria = obt.id 
and acomp_gestor.id_tipo_acompanhamento_ator = 1 
left join s2gpr_mcc.acompanhamento acomp_col on acomp_col.id_ordem_bancaria = 
obt.id and acomp_col.id_tipo_acompanhamento_ator = 2 
where i.numero = '968340' and id_situacao_ordem_bancaria = 5 and 
acomp_gestor.data_cadastro is null 
--group by obt.id, numero_obt, obt.data_cadastro, data_tipo, valor_obt, 
tob.nome, vps.nome, fp.nome_razao_social, i.id 
order by obt.id limit 5 offset 0 

PLANO EM PRODUCAO

"Limit  (cost=23012.24..23012.27 rows=1 width=150) (actual 
time=131530.596..131530.614 rows=5 loops=1)"
"  ->  Unique  (cost=23012.24..23012.27 rows=1 width=150) (actual 
time=131530.596..131530.613 rows=5 loops=1)"
"->  Sort  (cost=23012.24..23012.25 rows=1 width=150) (actual 
time=131530.594..131530.595 rows=5 loops=1)"
"  Sort Key: obt.id, obt.version, obt.numero_obt, 
obt.data_cadastro, obt.data_tipo, obt.valor_obt, tob.nome, "*SELECT* 1".nome, 
fp.nome_razao_social, i.id"
"  Sort Method: quicksort  Memory: 293kB"
"  ->  Nested Loop Left Join  (cost=3682.33..23012.23 rows=1 
width=150) (actual time=168.595..131525.268 rows=1009 loops=1)"
"Join Filter: (acomp_col.id_ordem_bancaria = obt.id)"
"->  Nested Loop Left Join  (cost=3682.33..21063.45 rows=1 
width=150) (actual time=154.918..120925.273 rows=998 loops=1)"
"  ->  Nested Loop  (cost=3682.33..21063.13 rows=1 
width=128) (actual time=154.896..120906.475 rows=998 loops=1)"
"Join Filter: (obt.id_parceiro = "*SELECT* 
1".id)"
"->  Nested Loop  (cost=1570.57..3430.41 rows=1 
width=105) (actual time=23.695..43.001 rows=998 loops=1)"
"  ->  Hash Right Join  
(cost=1570.57..3430.13 rows=1 width=80) (actual time=23.679..26.522 rows=998 
loops=1)"
"Hash Cond: 
(acomp_gestor.id_ordem_bancaria = obt.id)"
"Filter: 
(acomp_gestor.data_cadastro IS NULL)"
"->  Seq Scan on acompanhamento 
acomp_gestor  (cost=0.00..1816.54 rows=11463 width=16) (actual 
time=0.006..10.454 rows=11602 loops=1)"
"  Filter: 
(id_tipo_acompanhamento_ator = 1)"
"->  Hash  (cost=1570.45..1570.45 
rows=10 width=80) (actual time=11.260..11.260 rows=2619 loops=1)"
"  Buckets: 1024  Batches: 1  
Memory Usage: 318kB"
"  ->  Hash Join  
(cost=8.28..1570.45 rows=10 

Re: [pgbr-geral] quando usar vacuum full analyze

2016-08-31 Por tôpico Euler Taveira
On 31-08-2016 20:22, Luiz Henrique wrote:
> Estou com problema de lentidão em uma determinada consulta no banco de
> produção (centos linux postgresql 9.1). Tempo de 1 minuto em produção.
> No ambiente de homologação leva cerca de 3s. O banco de produção é
> copiado diariamente para homologação (em homol eu faço : dropdb,
> createdb e pg_restore). Ambientes prod e homol praticamente iguais.
> Pergunta :
> 
> o vacuum full analyze pode resolver meu problema ?
>
Sim. É como matar uma mosca com uma 12.

> quando usar vacuum full analyze ?
>
(quase) nunca. Só em casos extremos de inchaço (não sei se esse é o seu
problema já que não apresentou informações).

> alguma dica ou pista de como identificar a causa ?
> 
Comece por mostrar os planos da consulta na produção e na homologação.


-- 
   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

[pgbr-geral] quando usar vacuum full analyze

2016-08-31 Por tôpico Luiz Henrique
Pessoal,

Estou com problema de lentidão em uma determinada consulta no banco de
produção (centos linux postgresql 9.1). Tempo de 1 minuto em produção. No
ambiente de homologação leva cerca de 3s. O banco de produção é copiado
diariamente para homologação (em homol eu faço : dropdb, createdb e
pg_restore). Ambientes prod e homol praticamente iguais. Pergunta :

o vacuum full analyze pode resolver meu problema ?
quando usar vacuum full analyze ?
alguma dica ou pista de como identificar a causa ?
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral