[
https://issues.apache.org/jira/browse/OAK-2341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14241112#comment-14241112
]
Vikas Saurabh edited comment on OAK-2341 at 12/10/14 2:04 PM:
--------------------------------------------------------------
With {{counter}} index, we can scale down cost for a given path restriction as
{{currentCalcCost / approx-whole-tree-node-count *
approx-path-restricted-node-count}. While it won't be the most accurate way to
do the scaling... but, should still be better than nothing :).
Note, we need to take care that case2->step2 is already considering the path
restriction. We probably should remove that optimization and resort to scaling
cost as mentioned above.
was (Author: catholicon):
With {{counter}} index, we can scale down cost for a given path restriction as
{{currentCalcCost / approx-whole-tree-node-count *
approx-path-restricted-node-count}. While it won't be the most accurate way to
do the scaling... but, should still be better than nothing :).
> Use approx counters property index costs even when path restriction is
> available
> --------------------------------------------------------------------------------
>
> Key: OAK-2341
> URL: https://issues.apache.org/jira/browse/OAK-2341
> Project: Jackrabbit Oak
> Issue Type: Bug
> Affects Versions: 1.1.3
> Reporter: Vikas Saurabh
>
> Currently, cost calculation of property index follows following psuedo-code:
> * For "is not null" case:
> ## return {{entryCount}} || approximate counted indexed nodes
> ## if above doesn't work out, do a partial traversal and return extrapolated
> cost
> * For property in (a, b, ...) or property==value case:
> ## return {{entryCount}}/{{keyCount}} || approximate counted index nodes for
> each key (a, b, etc)
> ## if above doesn't work out, do a partial traversal over whole indexed tree
> or sub-tree (if path restriction is available) and return extrapolated cost
> approx counter on index is used only if {{entryCount}} property is missing in
> index definition node.
> The issue in step 1 in both cases is that it doesn't consider path
> restriction if it's given in the query.
> The only place where path restriction is being considered is in case2->step2.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
