Re: NOT IN subquery optimization - Mailing list pgsql-hackers

From Tom Lane
Subject Re: NOT IN subquery optimization
Date
Msg-id 2284.1551482036@sss.pgh.pa.us
Whole thread Raw
In response to Re: NOT IN subquery optimization  ("Li, Zheng" <zhelli@amazon.com>)
Responses Re: NOT IN subquery optimization
List pgsql-hackers
"Li, Zheng" <zhelli@amazon.com> writes:
> Although adding "or var is NULL" to the anti join condition forces the planner to choose nested loop anti join, it is
alwaysfaster compared to the original plan. 

TBH, I am *really* skeptical of sweeping claims like that.  The existing
code will typically produce a hashed-subplan plan, which ought not be
that awful as long as the subquery result doesn't blow out memory.
It certainly is going to beat a naive nested loop.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Why don't we have a small reserved OID range for patch revisions?
Next
From: David Rowley
Date:
Subject: Re: NOT IN subquery optimization