Eduardo,
Sobre a consulta:
Em 12 de novembro de 2011 14:05, Eduardo Santos
<[email protected]> 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)
> 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
O trecho :
(select site_node__url(site_nodes.node_id)
from site_nodes
where site_nodes.object_id = forums_forums.package_id) as url
Talvez fosse melhor se estivesse fora de um subselect. Mas como não
sei qual é o código da função site_note__url, então até pode ser pior
se fizer como eu disse.
Precisa medir o desempenho das funções chamadas em
"acs_object__name(apm_package__parent_id(forums_forums.package_id)) as
parent_name". Se existir um comportamento diferente e mais custoso na
versão mais nova, pode ser aqui o seu problema.
O trecho "case when last_post > (cast(current_timestamp as date)- 1)
then 't' else 'f' end as new_p", você poderia deixar como "last_post >
(cast(current_timestamp as date)- 1) as new_p". Mas isso é estético e
não influencia em desempenho.
Mas olhando o plano enviado anteriormente, tem esse trecho estranho aqui:
-> Nested Loop (cost=0.00..982907.73 rows=397639583
width=4) (actual time=0.102..1117.157 rows=1396734 loops=67)
-> Nested Loop (cost=0.00..12218.50 rows=45973
width=4) (actual time=0.073..0.487 rows=92 loops=67)
Join Filter: ((p.privilege)::text = (pdm.privilege)::text)
-> Seq Scan on acs_privilege_descendant_map pdm
(cost=0.00..9.23 rows=3 width=13) (actual time=0.025..0.025 rows=1
loops=67)
Filter: ((descendant)::text =
'read_private_data'::text)
-> Nested Loop (cost=0.00..549.81 rows=281596
width=14) (actual time=0.037..0.364 rows=231 loops=67)
-> Index Scan using
party_member_member_idx on party_approved_member_map pamm
(cost=0.00..25.68 rows=18 width=4) (actual time=0.018..0.018 rows=1
loops=67)
Index Cond: (member_id = 3443)
-> Index Scan using
acs_permissions_grantee_idx on acs_permissions p (cost=0.00..28.92
rows=16 width=18) (actual time=0.015..0.255 rows=231 loops=67)
Index Cond: (p.grantee_id = pamm.party_id)
-> Index Scan using acs_obj_ctx_idx_ancestor_idx on
acs_object_context_index c (cost=0.00..13.14 rows=638 width=8)
(actual time=0.008..6.993 rows=15182 loops=6164)
Index Cond: (c.ancestor_id = p.object_id)
No plano anterior havia:
-> Index Scan using
acs_obj_ctx_idx_object_id_idx on acs_object_context_index c
(cost=0.00..17.37 rows=48 width
=4) (actual time=10.316..11.088 rows=3 loops=67)
Index Cond: (object_id = $0)
Isso mostra que alguma coisa mudou para que fosse escolhida uma busca
inicial na tabela acs_object_context_index, e na versão nova é
escolhido um nested loop sobre outro índice.
Imagino que as funções mencionadas anteriormente sejam funções SQL. Correto?
Nossa, fazia tempo que não via algo divertido para analisar, está
sendo legal participar da lista.
--
Daniel Cristian Cruz
クルズ クリスチアン ダニエル
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
