Re: Memoize ANTI and SEMI JOIN inner

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Alena Rybakina <a(dot)rybakina(at)postgrespro(dot)ru>
Cc: Andrei Lepikhov <lepihov(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Memoize ANTI and SEMI JOIN inner
Date: 2025-03-31 03:33:03
Message-ID: CAApHDvpd-qnqgpCmLnb-T8yNjtFUX4J65D7+pOEz67dRs1+Ldg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 31 Mar 2025 at 16:21, Alena Rybakina <a(dot)rybakina(at)postgrespro(dot)ru> wrote:
> However, is it necessary to check that extra->inner_unique must be false for SEMI/ANTI joins here, or am I missing something? It looks a little confusing at this point.

If it is necessary, I don't see the reason for it. It was me that
worked on unique joins and I see no reason why a SEMI or ANTI join
couldn't be marked as unique. The reason they're not today is that the
only point of the unique join optimisation is so that during
execution, the join nodes could skip to the next outer tuple after
matching the current outer to an inner. If the join is unique, then
there are no more join partners to find for the current outer after
matching it up once. With SEMI and ANTI joins, we skip to the next
outer tuple after finding a match anyway, so there's no point in going
to the trouble of setting the inner_unique flag.

I can't say definitively that we won't find a reason in the future
that we should set inner_unique for SEMI/ANTI joins, so I don't follow
the need for the Assert.

Maybe you're seeing something that I'm not. What do you think will
break if both flags are true?

David

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2025-03-31 03:51:06 Re: Change log level for notifying hot standby is waiting non-overflowed snapshot
Previous Message Alena Rybakina 2025-03-31 03:21:43 Re: Memoize ANTI and SEMI JOIN inner