Vahe Evoyan <vahe.evoyan@xxxxxxxxx> writes: > Merge Join (cost=0.00..2513.96 rows=1 width=72) (actual > time=127.361..473.687 rows=66460 loops=1) > Merge Cond: ((v1.dft_id = v2.dft_id) AND ((v1.key)::text = > (v2.key)::text)) > -> Index Scan using qor_value_self_join on qor_value v1 > (cost=0.00..1255.60 rows=275 width=51) (actual time=89.549..97.045 > rows=1388 loops=1) > Index Cond: ((run_id = 60807) AND (stat_id = 342)) > -> Index Scan using qor_value_self_join on qor_value v2 > (cost=0.00..1255.60 rows=275 width=51) (actual time=37.796..134.286 > rows=66343 loops=1) > Index Cond: ((run_id = 60875) AND (stat_id = 342)) > Total runtime: 544.646 ms > (7 rows) > Note that the second Index Scan has 66343 rows in place of 1388. That's not a bug. That's a result of rescanning portions of the inner relation's output due to duplicate mergejoin keys in the outer relation. The EXPLAIN ANALYZE machinery counts the re-fetches as if they were new rows, though in some sense they're not. regards, tom lane -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
