MIME-Version: 1.0
References: 
 <CA+i5JwYoxnYGHXn41AgnN9iJP8FCMDMozgzsn5hc0tvhSSMNVg@mail.gmail.com>
In-Reply-To: 
 <CA+i5JwYoxnYGHXn41AgnN9iJP8FCMDMozgzsn5hc0tvhSSMNVg@mail.gmail.com>
From: David Rowley <dgrowleyml@gmail.com>
Date: Tue, 11 Apr 2023 21:33:42 +1200
Message-ID: 
 <CAApHDvox+8heOrYyD5Y8gpz6+wcj0w4Th2gT9+msOaH__4eFGQ@mail.gmail.com>
Subject: Re: Looking for an efficient way to replace efficient NOT IN when
 landling very large data
To: Shaozhong SHI <shishaozhong@gmail.com>
Cc: pgsql-sql <pgsql-sql@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
 <https://www.postgresql.org/message-id/CAApHDvox%2B8heOrYyD5Y8gpz6%2Bwcj0w4Th2gT9%2BmsOaH__4eFGQ%40mail.gmail.com>
Precedence: bulk

On Tue, 11 Apr 2023 at 21:28, Shaozhong SHI <shishaozhong@gmail.com> wrote:
>
> Select a.id, a.name, b.id, b.name from a_large_table a, definitive b where (a.id, b.name) not in
> (select b.id, b.name from definitive b)
>
> is very slow.
>
> Is there a faster way to do so?

It depends on what your exact requirements are for the NULL handling
that NOT IN provides.  Do you need the query to return 0 rows if b.id
and b.name are null?  This question is moot if none of the columns or
either table allow NULLs.

If you don't require that, then you'll give the planner more
flexibility to choose a more efficient plan if you use NOT EXISTS
instead.

David