Re: Assert failure in try_nestloop_path()

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

In response to

Browse pgsql-hackers by date

  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