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
