[
https://issues.apache.org/jira/browse/OAK-12007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18040355#comment-18040355
]
Thomas Mueller commented on OAK-12007:
--------------------------------------
So the remaining tests that fail with the feature enabled are running facet
queries with "or" conditions. If they are force-converted to "union", the tests
succeed; if not, then they fail, because they are not converted to union. I
think the reason is that the cost of the union is higher than the non-union,
because the number of rows is low.
{noformat}
//*[@name = 'Node1' or @text = 't2' or @x = 'x3']/(rep:facet(text))
// fail:
select [jcr:path], [jcr:score], [rep:facet(text)] from [nt:base] as a where
[name] = 'Node1' or [text] = 't2' or [x] = 'x3']
indexDefinition: /oak:index/luceneGlobal
estimatedEntries: 1
luceneQuery: *:*
// success:
select [jcr:path], [jcr:score], [rep:facet(text)] from [nt:base] as a where
[name] = 'Node1'
union select [jcr:path], [jcr:score], [rep:facet(text)] from [nt:base] as a
where [text] = 't2'
union select [jcr:path], [jcr:score], [rep:facet(text)] from [nt:base] as a
where [x] = 'x3'
indexDefinition: /oak:index/luceneGlobal
luceneQuery: name:Node1
indexDefinition: /oak:index/luceneGlobal
luceneQuery: text:t2
indexDefinition: /oak:index/luceneGlobal
luceneQuery: x:x3
{noformat}
> XPath with "or" conditions should not always be converted to "union"
> --------------------------------------------------------------------
>
> Key: OAK-12007
> URL: https://issues.apache.org/jira/browse/OAK-12007
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: query
> Reporter: Thomas Mueller
> Priority: Major
>
> In OAK-1432, XPath queries with "or" conditions are always converted to
> "union" queries.
> There are some queries that do not benefit from this forced conversion to
> "union", for example queries that use elasticsearch indexes for both parts,
> but where one of the properties is not indexed. In general, it would be
> better to compare the cost of the union with the cost of the non-union query,
> and then pick the one with the lower cost.
> In fact, for SQL-2 queries with "or" conditions, that is how it's working
> since OAK-1617.
> It's a bit dangerous now (after such a long time) to always disable the
> forced "union" conversion for XPath queries. But, what we could do is disable
> the forced conversion using a feature toggle.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
