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 > time=0.102..1117.157 rows=1396734 loops=67) > > ele estimou que existiriam 397.639.583 linhas quando, na realidade, > existiam 1.396.734 linhas. > > Rode novamente sua consulta com as estatísticas atualizadas e avalie o > resultado. > > A versão que você está utilizando é a 8.4.9? > Eu executei o vacuum full com analyze, rodei novamente a consulta e não obtive resultados muito diferentes. A versão é a 8.4.9 sim. Seria necessário executar o vacuum mesmo com o autovacuum ligado? Também não entendi como ele conseguiu ter resultados tão diferentes entre duas versão do PostgreSQL, mas aconteceu. Euler, Seguem respostas: 8.4.oque? 8.4.9 > Você executou a EXPLAIN ANALYZE várias vezes para se certificar de > que a diferença de tempo não é por causa de uma "partida a frio" da versão > 8.4? Sim, essa foi a primeira coisa que pensei. Executei várias vezes e os resultados não mudam muito. > Qual é a consulta? Desculpe, esqueci de anexar a consulta. É uma consulta realmente feia, mas que não chegava a ser um desastre no banco: 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) from site_nodes where site_nodes.object_id = forums_forums.package_id) as url, forums_forums.forum_id, forums_forums.name, case when last_post > (cast(current_timestamp as date)- 1) then 't' else 'f' end as new_p from forums_forums_enabled forums_forums, acs_objects where acs_objects.object_id = forums_forums.forum_id and forums_forums.package_id in (0,840191,1486834,626929,520062,1101742,1160464,1161067,2750196,3500360,133998,3673774,3676596,3686932,4860207,5986896,10050612,10157702,4645,93855,3186091,601355,22297512,6552691,21650654,8265465,23731964,33752302,15316177) and exists ( select 1 from acs_object_party_privilege_map ppm where ppm.object_id = forums_forums.package_id and ppm.party_id = '3443' and ppm.privilege = 'read_private_data' ) order by parent_name, forums_forums.name Uma das coisas que me chamaram atenção foi a estimativa do índice > acs_obj_ctx_idx_ancestor_idx. Qual a definição da tabela > acs_object_context_index? A definição é a seguinte: Tabela "public.acs_object_context_index" Coluna | Tipo | Modificadores ---------------+---------+--------------- object_id | integer | não nulo ancestor_id | integer | não nulo n_generations | integer | não nulo Índices: "acs_object_context_index_pk" PRIMARY KEY, btree (object_id, ancestor_id) "acs_obj_ctx_idx_ancestor_idx" btree (ancestor_id) "acs_obj_ctx_idx_object_id_idx" btree (object_id) Restrições de verificação: "acs_obj_context_idx_n_gen_ck" CHECK (n_generations >= 0) Restrições de chave estrangeira: "acs_obj_context_idx_anc_id_fk" FOREIGN KEY (ancestor_id) REFERENCES acs_objects(object_id) "acs_obj_context_idx_obj_id_fk" FOREIGN KEY (object_id) REFERENCES acs_objects(object_id) 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. Sabe me dizer se houve alguma mudança significativa no otimizados entre as versões 8.2 e 8.4? -- Eduardo Santos Analista de Sistemas http://eduardosan.wordpress.com http://twitter.com/eduardosan
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral