| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | chang chao <chang-chao(at)hotmail(dot)com> |
| Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: explain analyze does not report actual rows correctly? |
| Date: | 2016-05-18 17:16:03 |
| Message-ID: | 13962.1463591763@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
chang chao <chang-chao(at)hotmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ashutosh Bapat | 2016-05-18 17:37:42 | Re: Postgres_fdw join pushdown - getting server crash in left outer join of three table |
| Previous Message | Craig Ringer | 2016-05-18 16:27:33 | Re: foreign table batch inserts |