On Fri, Mar 20, 2015 at 8:34 AM, Luiz Carlos L. Nogueira Jr. < [email protected]> wrote:
> SET enable_seqscan TO on; > explain analyze > SELECT ppe.id_processo_parte_expediente, > ppe.id_pessoa_parte AS id_destinatario > FROM tb_proc_parte_expediente ppe > where exists (select 1 from tb_processo_expediente pe where > pe.id_processo_expediente::integer = ppe.id_processo_expediente::integer); > > > Hash Semi Join (cost=22122.22..53155.35 rows=724909 width=8) (actual > time=812.730..*2167.514* rows=724909 loops=1) > ... > Total runtime: *2438.293 ms* > > Só funciona com o off > > Merge Join (cost=10.97..149413.09 rows=724909 width=8) (actual > time=0.034..*2247.658* rows=724909 loops=1) > ... > Total runtime: *2522.453 ms* > > Se reparar vai ver que com seqscan=off (e usando os índices), o tempo de execução ficou maior. De fato não *muito* maior, talvez até empate em várias execuções. Mas de qualquer forma eu diria que o PostgreSQL fez uma excelente escolha em não usar o índice nesse caso, e você não devia então estar tentando forçá-lo a usar. Talvez a solução seja analisar o porquê você precisa de trazer ~725k linhas de uma vez só. 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
