Com e sem seq_scan. O tempo não melhorou muito, mas o custo......
Hash Join (cost=22122.22..53155.35 rows=724909 width=8) (actual
time=848.384..2502.618 rows=724909 loops=1)
Hash Cond: ((ppe.id_processo_expediente)::integer =
(pe.id_processo_expediente)::integer)
-> Seq Scan on tb_proc_parte_expediente ppe (cost=0.00..17441.09
rows=724909 width=12) (actual time=0.005..329.714 rows=724909 loops=1)
-> Hash (cost=13160.43..13160.43 rows=716943 width=4) (actual
time=847.997..847.997 rows=716943 loops=1)
Buckets: 131072 Batches: 1 Memory Usage: 25206kB
-> Seq Scan on tb_processo_expediente pe (cost=0.00..13160.43
rows=716943 width=4) (actual time=0.008..334.849 rows=716943 loops=1)
Total runtime: 2771.133 ms
Merge Join (cost=10.97..149413.09 rows=724909 width=8) (actual
time=0.040..2172.588 rows=724909 loops=1)
Merge Cond: ((pe.id_processo_expediente)::integer =
(ppe.id_processo_expediente)::integer)
-> Index Only Scan using tb_processo_expediente_pkey on
tb_processo_expediente pe (cost=0.42..25786.66 rows=716943 width=4)
(actual time=0.022..484.791 rows=716943 loops=1)
Heap Fetches: 716943
-> Index Scan using idx_tb_processo_parte_expediente2 on
tb_proc_parte_expediente ppe (cost=0.42..112777.29 rows=724909 width=12)
(actual time=0.011..687.923 rows=724909 loops=1)
Total runtime: 2436.261 ms
Em 19 de março de 2015 16:54, Marcos Thomaz <[email protected]>
escreveu:
>
>
> Em 19 de março de 2015 14:49, Matheus de Oliveira <
> [email protected]> escreveu:
>
>>
>> 2015-03-19 16:38 GMT-03:00 Luiz Carlos L. Nogueira Jr. <
>> [email protected]>:
>>
>> explain analyze
>>> SELECT ppe.id_processo_parte_expediente,
>>> ppe.id_pessoa_parte AS id_destinatario
>>> FROM tb_proc_parte_expediente ppe
>>> JOIN tb_processo_expediente pe ON ppe.id_processo_expediente::integer
>>> = pe.id_processo_expediente::integer
>>>
>>>
>>>
>>> Hash Join (cost=22106.25..53111.83 rows=724368 width=8) (actual
>>> time=861.768..2466.032 rows=724368 loops=1)
>>> Hash Cond: ((ppe.id_processo_expediente)::integer =
>>> (pe.id_processo_expediente)::integer)
>>> -> Seq Scan on tb_proc_parte_expediente ppe (cost=0.00..17423.68
>>> rows=724368 width=12) (actual time=0.007..317.210 rows=724368 loops=1)
>>> -> Hash (cost=13151.11..13151.11 rows=716411 width=4) (actual
>>> time=861.567..861.567 rows=716411 loops=1)
>>> Buckets: 131072 Batches: 1 Memory Usage: 25187kB
>>> -> Seq Scan on tb_processo_expediente pe (cost=0.00..13151.11
>>> rows=716411 width=4) (actual time=0.010..322.964 rows=716411 loops=1)
>>> Total runtime: 2732.053 ms
>>>
>>>
>>> Tabela tb_proc_parte_expediente (Tamanho 80MB)
>>>
>>> índice idx_tb_processo_parte_expedienteubd (tamanho 22MB)
>>> ON client.tb_proc_parte_expediente
>>> (id_processo_expediente,id_processo_parte_expediente,id_pessoa_parte);
>>>
>>> e a pk de tb_processo_expediente é id_processo_expediente
>>>
>>> Por que é feito o seq scan nas tabelas e não usam os índices/pks, já
>>> que ele contem os campos da query e seus tamanhos são bem menores?
>>>
>>> Teria alguma configuração que pudesse "forçar" isso?
>>>
>>
>>
>> É comum ter um HashJoin quando você quer fazer junção em grandes
>> conjuntos de dados, e como você está de fato lendo as tabelas inteiras, o
>> acesso sequencial lendo a tabela toda é preferido ao invés do acesso
>> aleatório na leitura do índice.
>>
>> Nem sempre usar índice é mais rápido, e esse parece ser um caso do tipo.
>> Se quiser tentar verificar, desabilite o seq-scan *somente para essa
>> consulta* e verifique o resultado:
>>
>> SET enable_seqscan TO off;
>> EXPLAIN ...
>>
>> Atenciosamente,
>> --
>> Matheus de Oliveira
>> Analista de Banco de Dados
>> Dextra Sistemas - MPS.Br nível F!
>> www.dextra.com.br/postgres
>>
>>
>> _______________________________________________
>> pgbr-geral mailing list
>> [email protected]
>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>
>>
>
>
> Luiz, se o seu select for apenas esse (mão for necessitar dos campos de
> tb_processo_expediente), você pode utilizar o exists.
>
> --
>
>
> Marcos Thomaz da Silva
> Analista de Tecnologia da Informação
>
> _______________________________________________
> 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
