Simon Riggs wrote:
I think Tom is refering to the context of the specific optimization.Tom Lane writes In the second place, what the code is doing is dependent on an understanding of the semantics of IN; I'm not sure it's applicable to, say, WHERE outervar > ANY (SELECT innervar FROM ...) and it's definitely not applicable to WHERE outervar > ALL (SELECT innervar FROM ...) In particular, the optimization paths that involve unique-ifying the subselect output and then using it as the outer side of a join would definitely not work for these sorts of things.I'm not sure if I've understood you correctly in the section above. Are you saying that these types of queries don't have a meaningful or defined response? Or just that they wouldn't be very well optimized as a result of the unique-ifying code changes? Or have I just mis-read the thread... The optimization we are discussing does nothing to correlated subqueries, and a uncorrolated subquery with > ALL/ANY is actually a computed constant and not a join. -- Dennis |