Thanks for making that comment. I should have stated explicitly that the query was not logically the same and could be expected to return a different answer. The reason for the comparison was to point out that a surprisingly similar type of query (equality on two columns out of three). In fact I think I’ve even seen cases where the optimizer has turned “in (list of values)” into a range scan that discarded unwanted values – I’ll have to see if I can find time to engineer an example.

Thanks for sharing the problem and excellent analysis of it as well as the clever solution.
Just one doubt. You said in the “Update” On the other hand, it is possible to get unnesting and a hash anti-join with the predicate: id3 between id2 and id2 + 1000.
But won’t that make the query different to the original query? id3 between id2 and id2 + 1000 is not equivalent to (id3 = id2 or id3 = id2 + 1000). Or is it because of the nature of data that these two predicates will produce same results? Or did I miss something obvious?

Thanks for the follow-up.

Yes as of now the CBO does not unnest correlated subquery with OR predicates, ER 14113785 has been filed about it
Non-correlated are covered by fix for Bug 9143856, details in Doc ID 9143856.8

I had a look at both bugs (this comment, and the next), and I don’t think either of them really relates to the shape of query I have. Both are about semi-joins, and the 10g bug relates to tableA with subquery being joined to tableB with subquery, and the positioning of the two separate subqueries.

Given my additional comment about the query working with a range predicate for the third column – it really does look as if a concatenation (or probably inlist iterator) method could and should apply in this case inside the unnest.

We didn’t raise an SR – it’s the usual problem, once you’ve worked around a problem you move on to the next one. It would have taken a couple of hours to raise the SR. It’s possible that someone from Oracle might read the blog though, and follow it up.

again the “less than” issue.
I’ve checked this on 11.2.0.3 and it shows same behavior with the same message in 10053 trace.
And a question: did your client file an SR for this trouble? I think that would be a very nice feature request to the optimizer team, especially since they already can do opposite type of transformation called coalescing with multiple subqueries (in some cases).