Re: Anti join confusion

From: Tender Wang <tndrwang(at)gmail(dot)com>
To: Richard Guo <guofenglinux(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, wenhui qiu <qiuwenhuifx(at)gmail(dot)com>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Anti join confusion
Date: 2025-03-03 07:57:31
Message-ID: CAHewXN=O390+7xB+BM-DLSG29Tfy4152Rwq7dkMAxDAfQpY98A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Richard Guo <guofenglinux(at)gmail(dot)com> 于2025年3月3日周一 15:34写道:

> On Wed, Feb 26, 2025 at 7:09 PM Tender Wang <tndrwang(at)gmail(dot)com> wrote:
> > Recently, I found Greenplum implement pull-up NOT IN subquery. They have
> the below comments in their codes:
> >
> > We normalize NOT subqueries using the following axioms:
> > *
> > * val NOT IN (subq) => val <> ALL (subq)
> >
> > Richard, do you have an impression about this?
>
> I vaguely recall that Greenplum converts NOT IN to some form of join
> in certain cases, but I can't remember the details.
>

I do some research about Greenplum planner work for the NOT IN, I think the
way they do is just like the second option you said:

* We can add support in the executor to handle the NULL semantics of
NOT IN. This may require inventing a new join type.

1.
They add a new join type left anti semi join
2.
The executor code can handle the case when the inner side returns NULL
tuple.

I‘m not sure this transformation is only available for certain cases. I
will continue to research.
I may provide a POC patch based on the Greenplum way.

--
Thanks,
Tender Wang

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Hayato Kuroda (Fujitsu) 2025-03-03 07:57:32 Selectively invalidate caches in pgoutput module
Previous Message Zhijie Hou (Fujitsu) 2025-03-03 07:41:08 RE: long-standing data loss bug in initial sync of logical replication