Hello team, back in 1.3.9 we introduced https://issues.apache.org/jira/browse/OAK-1617 which indirectly addressed https://issues.apache.org/jira/browse/OAK-2660 and https://issues.apache.org/jira/browse/OAK-2539.
This has been proven to work out fine. However if we come from an xpath query which has been already converted into UnionImpl, it won't be optimised. With optimisation it's meant: converting, as of now, OR into UNION. There are some cases where the two issues could appear within one or more of the queries of UnionImpl. So my idea is: could we attempt a generation of UnionImpl off Query within UnionImpl? It's a kind-of recursive thing. On paper I don't see any problem as something like select * from [nt:base] where [a] = 1 OR [b] = 2 union select * from [nt:base] where [c] = 3 OR [d] = 4 would be translated into select * from [nt:base] where [a] = 1 union select * from [nt:base] where [b] = 2 union select * from [nt:base] where [c] = 3 union select * from [nt:base] where [d] = 4 It should give the same resultset. Shouldn't it? The framework in place with OAK-1617 already adopt a cost oriented model. So with little changes we could generate more than one alternatives and peak the cheapest one. thoughts? Davide
