Analise fortemente migrar para o 9.1.
2011/11/12 Eduardo Santos <[email protected]> > 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 > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > >
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
