| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Richard Guo <guofenglinux(at)gmail(dot)com> |
| Cc: | Tender Wang <tndrwang(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Assert failure in try_nestloop_path() |
| Date: | 2026-09-04 13:50:47 |
| Message-ID: | 1558537.1788529847@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Richard Guo <guofenglinux(at)gmail(dot)com> writes:
> I looked into it. What happens here is that outer-join identity 3
> permits the join to t3 to commute with the a/b left join, so we
> generate multiple clones of "b.q1 = t3.cnt", differing in the
> nullingrels of b.q1. Only one of them should be applied in any given
> plan. However, when movable join clauses are pushed down into a
> parameterized path, we fail to choose among the clones.
Yup, clearly an oversight. Your fix LGTM. I'm not sure that we
should push it into stable branches: it might destabilize queries that
people are happy with, and we don't have field complaints about it.
But v19 should still be fair game at this point.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jan Nidzwetzki | 2026-09-04 13:51:06 | Re: Re:[PATCH] Speed up repeat() for larger counts |
| Previous Message | Jakub Wartak | 2026-09-04 13:37:10 | Re: [(known) BUG] DELETE/UPDATE more than one row in partitioned foreign table |