> Como eu suspeitava, você melhorou alguma coisa o plano de execução.
> Importa-se de publicá-lo na lista?
Consegui melhorar Bastante o plano de execução invertendo a tabela no
qual é realizada o seqScan Inicial :
EXPLAIN SELECT L.id_log,RL.id_log FROM tzrepl.tzr_replicated_log RL
RIGHT OUTER JOIN tzrepl.tzr_log L ON L.id_log = RL.id_log
WHERE RL.id_log IS NULL
"Merge Left Join (cost=294375.00..313603.71 rows=861971 width=8)"
" Merge Cond: ("outer".id_log = "inner".id_log)"
" Filter: ("inner".id_log IS NULL)"
" -> Sort (cost=138438.33..140593.25 rows=861971 width=4)"
" Sort Key: l.id_log"
" -> Seq Scan on tzr_log l (cost=0.00..22779.71 rows=861971 width=4)"
" -> Sort (cost=155936.67..158423.15 rows=994590 width=4)"
" Sort Key: rl.id_log"
" -> Seq Scan on tzr_replicated_log rl (cost=0.00..20996.90
rows=994590 width=4)"
Assim, ele me retorna 143662 registros (6/5 - 861971 (Log) / 718309
(replicated_log)) em apenas 14094ms.
Mas mesmo assim vou tentar implementar o num_repl, que reduzirá ainda
mais a quantidade de linhas do primeiro seqScan...
O que acham ?
Att:
Thiago Risso
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
