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?
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
