On Wed, 27 Feb 2019 at 03:07, Jim Finnerty <jfinn...@amazon.com> wrote: > > The problem is that the special optimization that was proposed for the case > where the subquery has no WHERE clause isn't valid when the subquery returns > no rows. That additional optimization needs to be removed, and preferably > replaced with some sort of efficient run-time test.
That is one option, however, the join type that Richard mentions, to satisfy point #3, surely only can work for Hash joins and perhaps Merge joins that required a sort, assuming there's some way for the sort to communicate about if it found NULLs or not. Either way, we need to have looked at the entire inner side to ensure there are no nulls. Probably it would be possible to somehow team that up with a planner check to see if the inner exprs could be NULL then just implement points #1 and #2 for other join methods. If you're proposing to do that for this thread then I can take my planner only patch somewhere else. I only posted my patch as I pretty much already had what I thought you were originally talking about. However, please be aware there are current patents around adding execution time smarts in this area, so it's probably unlikely you'll find a way to do this in the executor that does not infringe on those. Probably no committer would want to touch it. I think my patch covers a good number of use cases and as far as I understand, does not go near any current patents. Please let me know if I should move my patch to another thread. I don't want to hi-jack this if you're going in another direction. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
