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
Re: [pgbr-geral] Melhoria de performance - Por que não usa índice?
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
