Re: explain analyze does not report actual rows correctly? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: explain analyze does not report actual rows correctly?
Date
Msg-id 13962.1463591763@sss.pgh.pa.us
Whole thread Raw
In response to explain analyze does not report actual rows correctly?  (chang chao <chang-chao@hotmail.com>)
List pgsql-hackers
chang chao <chang-chao@hotmail.com> writes:
> The actual rows(rows=9950) part in the following line contained in the above query plan seems strange.
> "  ->  Sort  (cost=10.64..11.14 rows=200 width=520) (actual time=0.045..0.561 rows=9950 loops=1)"
> Shouldn't it be 200?

No, that's probably correct, seeing that this node is the righthand child
of a mergejoin.  The discrepancy is from extra fetches due to the same row
being re-fetched multiple times thanks to mark/restore rescanning.  What
explain is reporting is the number of rows pulled from the node, not the
number of unique rows it processed.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: foreign table batch inserts
Next
From: Ashutosh Bapat
Date:
Subject: Re: Postgres_fdw join pushdown - getting server crash in left outer join of three table