On Mon, Jul 14, 2014 at 3:00 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
David Rowley <dgrowleyml@gmail.com> writes: > I had another look at this and it appears you were right the first time, we > need to ensure there's no NULLs on both sides of the join condition.
Ugh. I'm back to being discouraged about the usefulness of the optimization.
Are you worried about the planning overhead of the not null checks, or is it more that you think there's a much smaller chance of a real world situation that the optimisation will succeed? At least the planning overhead is limited to query's that have NOT IN clauses.
I'm still quite positive about the patch. I think that it would just be a matter of modifying query_outputs_are_not_nullable() giving it a nice new name and changing the parameter list to accept not only a Query, but also a List of Expr. Likely this would be quite a nice reusable function that likely could be used in a handful of other places in the planner to optimise various other cases.
When I first decided to work on this I was more interested in getting some planner knowledge about NOT NULL constraints than I was interested in speeding up NOT IN, but it seemed like a perfect target or even "excuse" to draft up some code that checks if an expr can never be NULL.
Since the patch has not been marked as rejected I was thinking that I'd take a bash at fixing it up, but if you think this is a waste of time, please let me know.
