[
https://issues.apache.org/jira/browse/OAK-6123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15982439#comment-15982439
]
Thomas Mueller commented on OAK-6123:
-------------------------------------
That's true, it can be done in the query engine.
If the index implementation returns an iterator that makes entries unique
(avoid duplicates), then it would be better to do filtering in the index
implementation however. But I think that's not the case, except for the
AggregateIndex? The AggregateIndex is not as important however.
> Filter documents not matching path restriction in LucenePropertyIndex even
> when evaluatePathRestriction isn't set
> -----------------------------------------------------------------------------------------------------------------
>
> Key: OAK-6123
> URL: https://issues.apache.org/jira/browse/OAK-6123
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
> Reporter: Vikas Saurabh
> Assignee: Vikas Saurabh
> Priority: Minor
> Fix For: 1.8
>
>
> It's recommended to use {{evaluatePathRestriction}} on lucene index defs when
> the queries designed to be backed by that index would use path restriction
> heavily.
> But, since setting {{evaluatePathRestriction}} increases size of index, the
> choice to set it up needs to be thought out clearly.
> Currently, without {{evaluatePathRestriction}}, all the results which aren't
> part of path restriction in query are filtered in query-engine - which ends
> up loading the node from repository before filtering.
> We should be able improve the situation quite a bit by doing path filtering
> inside {{LucenePropertyIndex}}/{{LuceneIndex}}. Note, it's not a substitute
> of {{evaluatePathRestriction}} - just an optimization for cases where we
> don't want to set it and utilize path restrictions at times.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
