Re: [pgbr-geral] VACUUM FULL ANALYZE VERBOSE

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

Re: [pgbr-geral] pg_activity em Amazon RDS

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

Re: [pgbr-geral] pg_activity em Amazon RDS

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

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

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

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

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

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

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

Re: [pgbr-geral] pg_activity em Amazon RDS

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

Re: [pgbr-geral] VACUUM FULL ANALYZE VERBOSE

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]

Re: [pgbr-geral] Problemas de desempenho

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 >

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

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

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

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

[pgbr-geral] Problemas de desempenho

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

[pgbr-geral] RES: Problemas de desempenho

> 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

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

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"