On Mon, Jul 14, 2014 at 3:00 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> David Rowley <dgrowle...@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. Regards David Rowley
