[
https://issues.apache.org/jira/browse/OAK-6776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16191164#comment-16191164
]
Thomas Mueller commented on OAK-6776:
-------------------------------------
> but we should take deterministic path if traversal can be avoided.
That's still the case: if supportsPathRestrictions returns true, the cost of
the index is scaled down to the expected number of nodes in this tree, and is
at most the number of expected nodes in that tree. So traversal will _alway_
lose in that case (deterministically).
Another index can still win however (for example a property index), if it
returns a lower cost. But that's the case even now (with OAK-6734).
> Correctly use IndexPlan.supportsPathRestrictions
> ------------------------------------------------
>
> Key: OAK-6776
> URL: https://issues.apache.org/jira/browse/OAK-6776
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
> Reporter: Thomas Mueller
> Assignee: Thomas Mueller
> Fix For: 1.8
>
>
> Right now, IndexPlan.supportsPathRestrictions (introduced in OAK-6734) is
> used in the query engine for some kind of mixed "rule based" and "cost based"
> [query optimization|https://en.wikipedia.org/wiki/Query_optimization].
> I think the current implementation isn't correct, as (for example) a query
> with multiple indexes will now use the wrong index in some cases (for example
> property index, even if the cost of the Lucene index is lower).
> Also, if there is a Lucene index with supportsPathRestrictions, and one
> without, right now always the one with supportsPathRestrictions is used. This
> is probably better right now, but once OAK-6735 is resolved, this should be
> fixed as well.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
