From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Nicolas Seinlet <nicolas(at)seinlet(dot)com> |
Cc: | "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: More records after sort |
Date: | 2021-07-20 14:34:37 |
Message-ID: | 368621.1626791677@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Nicolas Seinlet <nicolas(at)seinlet(dot)com> writes:
> I'm facing a strange behaviour and I don't understand why. From a wider query plan, https://explain.dalibo.com/plan/7yh ,a table is scanned and filter based on its primary key, returning 98 records. Then, those records are sorted on another field, and the output is 758,247,643 records.
You haven't showed us the whole plan; tsk tsk.
However, I'm going to bet that this sort is the inner input of a merge
join, and that the apparent "extra" tuples are caused by the merge backing
up and rescanning the sort result to deal with duplicate join keys in its
outer input. There must be a heck of a lot of duplicates. The planner
would typically avoid using merge join if it knew that, so I'm wondering
if you have up-to-date statistics for the outer side of the join.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Nicolas Seinlet | 2021-07-20 15:07:27 | Re: More records after sort |
Previous Message | Nicolas Seinlet | 2021-07-20 14:25:29 | More records after sort |