Eduardo,
Sobre a consulta:
Em 12 de novembro de 2011 14:05, Eduardo Santos
eduardo.edusan...@gmail.com escreveu:
select forums_forums.package_id,
acs_object__name(apm_package__parent_id(forums_forums.package_id))
as parent_name,
(select site_node__url(site_nodes.node_id)
Pessoal,
Estava com alguns problemas de lock e decidi atualizar minha versão do
PostgreSQL da 8.2 para a 8.4, onde muitos avanços foram feitos nesse campo.
Contudo, para minha surpresa, a performance caiu drasticamente. O curioso é
que as máquinas físicas são idênticas fisicamente e mantive
Le 2011-N-12 11h38, Eduardo Santos a écrit :
Estava com alguns problemas de lock
Que problemas? Normalmente, a questão não é versão mas programação do
aplicativo…
decidi atualizar minha versão do PostgreSQL da 8.2 para a 8.4
Por que para uma versão tão antiga? Já estamos na 9.1, que
Olá Dutra,
Obrigado pela resposta. Seguem comentários.
Em 12 de novembro de 2011 12:14, Leandro Guimarães Faria Corcete DUTRA
l...@dutras.org escreveu:
Le 2011-N-12 11h38, Eduardo Santos a écrit :
Estava com alguns problemas de lock
Que problemas? Normalmente, a questão não é versão
2011/11/12 Eduardo Santos eduardo.edusan...@gmail.com:
Pessoal,
Estava com alguns problemas de lock e decidi atualizar minha versão do
PostgreSQL da 8.2 para a 8.4, onde muitos avanços foram feitos nesse campo.
Contudo, para minha surpresa, a performance caiu drasticamente. O curioso é
que as
Olá Osvaldo,
Obrigado pela resposta. Seguem comentários:
Pelos números apresentados tudo indica que suas estatísticas estavam
atualizadas o que levou o planejador a optar por caminhos
ineficientes.
Veja por exemplo:
Nested Loop (cost=0.00..982907.73 rows=397639583 width=4) (actual
On 12-11-2011 13:05, Eduardo Santos wrote:
Desculpe, esqueci de anexar a consulta. É uma consulta realmente feia, mas que
não chegava a ser um desastre no banco:
Um comentário: o PostgreSQL não se dá muito bem com listas grandes no IN. Os
valores vem de outra consulta, se sim, talvez seja
