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

From Li, Zheng
Subject Re: NOT IN subquery optimization
Date
Msg-id 4B5EFE62-C086-49BF-ABCF-D36DEE54DACE@amazon.com
Whole thread Raw
In response to Re: NOT IN subquery optimization  (David Rowley <david.rowley@2ndquadrant.com>)
Responses Re: NOT IN subquery optimization  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: NOT IN subquery optimization  (David Rowley <david.rowley@2ndquadrant.com>)
List pgsql-hackers
I agree we will need some runtime smarts (such as a new anti join type as pointed out by Richard) to "ultimately"
accountfor all the cases of NOT IN queries.
 

However, given that the March CommitFest is imminent and the runtime smarts patent concerns David had pointed out
(whichI was not aware of before), we would not move that direction at the moment.
 

I propose that we collaborate to build one patch from the two patches submitted in this thread for the CF. The two
patchesare for the same purpose and similar. However, they differ in the following ways as far as I can tell:
 

Nullability Test:
-David's patch uses strict predicates for nullability test.
-Our patch doesn't use strict predicates, but it accounts for COALESCE and null-padded rows from outer join. In
addition,we made reduce_outer_joins() work before the transformation which makes the nullability test more accurate.
 

Anti Join Transformation:
-Dvaid's patch does the transformation when both inner and outer outputs are non-nullable.
-With the latest fix (for the empty table case), our patch does the transformation as long as the outer is non-nullable
regardlessof the inner nullability, experiments show that the results are always faster.
 

David, please let me know what you think. If you would like to collaborate, I'll start merging with your code on using
strictpredicates to make a better Nullability Test.
 

Thanks,
Zheng


pgsql-hackers by date:

Previous
From: Paul Ramsey
Date:
Subject: Re: Allowing extensions to supply operator-/function-specific info
Next
From: Tom Lane
Date:
Subject: Re: Allowing extensions to supply operator-/function-specific info