[
https://issues.apache.org/jira/browse/OAK-9522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17398013#comment-17398013
]
Thomas Mueller commented on OAK-9522:
-------------------------------------
Merged in trunk. I want to backport it to the 1.22 branch as well.
> Index cost estimation: prefer union query with path restriction
> ---------------------------------------------------------------
>
> Key: OAK-9522
> URL: https://issues.apache.org/jira/browse/OAK-9522
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Reporter: Thomas Mueller
> Assignee: Thomas Mueller
> Priority: Major
> Labels: index, lucene, query
> Fix For: 1.42.0
>
>
> If there is a query of this form with an index that supports path
> restrictions (evaluatePathRestrictions = true):
> {noformat}
> select * from [nt:base] where [indexedProperty] = x
> and (issamenode('/content') or isdescendantnode('/content'))
> {noformat}
> then the path restriction isn't used in the index.
> This is unfortunate, because the index returns a lot more results, and the
> query engine will have to check if the path matches the condition.
> How this works: the query engine creates two possible queries:
> * plan a: one with just the [indexedProperty] = x condition, and no path
> restriction
> * plan b: a union query, where one side uses issamenode and the other side
> uses isdescendantnode.
> The index will return the same cost no matter if a path condition is there or
> not. And that's why the query engine will pick plan a: because the cost of
> the union query is higher.
> The index should return a lower cost if there is a path restriction. (Right
> now the query engine will reduce the cost if there is a path restriction, but
> that's not sufficient for this case).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
