Re: Wrong actual number of rows in the Query Plan - Mailing list pgsql-performance

From Tom Lane
Subject Re: Wrong actual number of rows in the Query Plan
Date
Msg-id 8621.1362074329@sss.pgh.pa.us
Whole thread Raw
In response to Wrong actual number of rows in the Query Plan  (Vahe Evoyan <vahe.evoyan@gmail.com>)
List pgsql-performance
Vahe Evoyan <vahe.evoyan@gmail.com> 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


pgsql-performance by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: xmlconcat performance
Next
From: "Carlo Stonebanks"
Date:
Subject: Re: Are bitmap index scans slow to start?