Hi Davide,

I think 'OR' gets passed as constraints to underlying index engine
(property, lucene, solr) etc. For lucene case (I guess solr too), I
think having a bunch is of 'OR' is more useful than doing a union at
query engine as:
* single query to lucene would save multiple hops into index
* lucene's default relevance sort is very useful (as it orders more
matched 'OR's over less matches)

So, while agree, that the result would be same at the end of day but
we 'might' get less performant.

Disclaimer: I'm assuming UNION implies 'solving each query
indepedently and provide union-ed result'. Ignore this mail, if that's
not the case.

Thanks,
Vikas

On Wed, Feb 3, 2016 at 4:25 PM, Davide Giannella <dav...@apache.org> wrote:
> 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
>
>

Reply via email to