Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UB7ks-0007wn-Cj for pgsql-performance@arkaria.postgresql.org; Thu, 28 Feb 2013 17:58:54 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.72) (envelope-from ) id 1UB7kr-0008OO-Lk for pgsql-performance@arkaria.postgresql.org; Thu, 28 Feb 2013 17:58:53 +0000 Received: from makus.postgresql.org ([2001:4800:7903:4::125]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UB7kq-0008OI-Hg for pgsql-performance@postgresql.org; Thu, 28 Feb 2013 17:58:52 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UB7kp-0004Xd-Gr for pgsql-performance@postgresql.org; Thu, 28 Feb 2013 17:58:51 +0000 Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.5/8.14.5) with ESMTP id r1SHwnq8008622; Thu, 28 Feb 2013 12:58:50 -0500 (EST) From: Tom Lane To: vahe.evoyan@gmail.com cc: pgsql-performance@postgresql.org Subject: Re: Wrong actual number of rows in the Query Plan In-reply-to: References: Comments: In-reply-to Vahe Evoyan message dated "Thu, 21 Feb 2013 11:24:27 +0400" Date: Thu, 28 Feb 2013 12:58:49 -0500 Message-ID: <8621.1362074329@sss.pgh.pa.us> X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org Vahe Evoyan 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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance