Re: Fix bogus Asserts in calc_non_nestloop_required_outer

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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-08 17:25:03
Message-ID: CA+TgmoYwKMv81_KMccbWq7tt5ukcrybo7qOQBDLSTnFx7dKPzg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Jan 6, 2024 at 4:08 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > 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.

I don't really understand what you were saying in your response there,
or what you're saying here. It seems to me that if the path is
parameterized by top relids, and the assertion is verifying that a
certain set of non-toprelids i.e. otherrels isn't present, then
obviously the assertion is going to pass, but it's not checking what
it purports to be checking. The ostensible purpose of the assertion is
to check that neither side is parameterized by the other side, because
a non-nestloop can't satisfy a parameterization. But with the
assertion as currently formulated, it would pass even if one side
*were* parameterized by the other side, because outer_paramrels and
inner_paramrels would contain child relations, and the set that it was
being compared to would contain only top-parents, and so they wouldn't
overlap.

--
Robert Haas
EDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2024-01-08 17:27:16 Re: Emit fewer vacuum records by reaping removable tuples during pruning
Previous Message Jelte Fennema-Nio 2024-01-08 17:19:53 Re: Commitfest 2024-01 first week update