Em 19 de março de 2015 14:49, Matheus de Oliveira <matioli.math...@gmail.com > escreveu:
> > 2015-03-19 16:38 GMT-03:00 Luiz Carlos L. Nogueira Jr. < > lcnogueir...@gmail.com>: > > 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 > pgbr-geral@listas.postgresql.org.br > 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 pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
