Re: [pgbr-geral] Melhoria de performance - Por que não usa índice?
Em 19 de março de 2015 14:49, Matheus de Oliveira 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
Re: [pgbr-geral] Melhoria de performance - Por que não usa índice?
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
[pgbr-geral] Melhoria de performance - Por que não usa índice?
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 pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
