Re: BUG #10816: explain analyze reports different rows counts before and after sort

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: bashtanov(at)imap(dot)cc
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #10816: explain analyze reports different rows counts before and after sort
Date: 2014-06-30 14:16:57
Message-ID: 4200.1404137817@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

bashtanov(at)imap(dot)cc writes:
> Please have a look at the two bottom nodes of the plan. Function scan
> produces 1000 rows, then they are sorted and turn into 3201 rows! How could
> this happen?

The discrepancy is easily explained because the sort is the righthand
child of a merge join. Merge join will rewind and rescan its right
child every time the left child produces duplicate keys, so that the
appropriate right-child rows get joined to all the similarly-keyed
rows from the left child. And you do have duplicate outputs coming
from that left child ...

IOW, it's just a measurement artifact arising from re-fetching the
same rows repeatedly. I think there's a warning about this in the
docs.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Michael Paquier 2014-06-30 20:14:13 Re: BUG #10817: archive settings
Previous Message rameshparnanditech 2014-06-30 13:01:55 BUG #10817: archive settings