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 prudente substituir esses valores por uma junção.
> Tabela "public.acs_object_context_index" > Parece-me que está tabela e/ou índice acs_obj_ctx_idx_ancestor_idx está(ão) inchado(s). Faça um VACUUM nessa tabela e um REINDEX no índice mencionado. Verifique se o plano muda. > > Ela funciona como uma tabela intermediária para facilitar a contagem da > quantidade de filhos que determinado objeto tem. É uma tentativa de evitar a > contagem num subselect, o que tornaria a consulta ainda mais lenta. > Você chegou a testar essa estratégia? Otimização precoce pode ser pior que nenhuma otimização. > Sabe me dizer se houve alguma mudança significativa no otimizados entre as > versões 8.2 e 8.4? > Várias mudanças. Vide notas de lançamento da 8.3 e 8.4. Outra coisa que notei foi que a cardinalidade (aka número de tuplas) das tabelas envolvidas parece ter tamanho diferentes entre as versões. Os bancos de dados são idênticos? Teste as várias estratégias apontadas e apresente os novos planos de consulta. -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
