Re: Fix bogus Asserts in calc_non_nestloop_required_outer

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Richard Guo <guofenglinux(at)gmail(dot)com>, Aleksander Alekseev <aleksander(at)timescale(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Fix bogus Asserts in calc_non_nestloop_required_outer
Date: 2024-01-06 21:08:57
Message-ID: 1354294.1704575337@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Fri, Jan 5, 2024 at 4:36 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I don't think I believe this code change, let alone any of the
>> explanations for it. The point of these Asserts is to be sure that
>> we don't form an alleged parameterization set that includes any rels
>> that are included in the new join, because that would be obviously
>> wrong. They do check that as they stand. I'm not sure what invariant
>> the proposed revision would be enforcing.

> Well, this explanation made sense to me:
> https://www.postgresql.org/message-id/CAMbWs4-%2BGs0HJ9ouBUb%3DqwHsGCXxG%2B92eJzLOpCkedvgtOWQ%3DQ%40mail.gmail.com

The argument for the patch as proposed is that we should make the
mergejoin and hashjoin code paths do what the nestloop path is doing.
However, as I replied further down in that other thread, I'm not
exactly convinced that the nestloop path is doing the right thing.
I've not had time to look closer at that, though.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2024-01-06 22:41:14 Re: Wrong rows estimations with joins of CTEs slows queries by more than factor 500
Previous Message Tom Lane 2024-01-06 20:59:36 Re: Wrong results with grouping sets