[
https://issues.apache.org/jira/browse/OAK-4233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15254083#comment-15254083
]
Vikas Saurabh commented on OAK-4233:
------------------------------------
Extra (invalid) rows returned from index are filtered by QueryEngine. Index
almost always give more results than what'd get percolated up to JCR. e.g. (1)
Query is adding 2 contstraint - while index known about only one (the most
common case in terms of prop indices), (2) Acl is another.
I couldn't come up with a case of duplicate rows in union - but if that's a
concern too then and assumming query engine implicitly does not do {{DISTINCT
jcr:path}}, then duplicate would need to be take care of as well (probably
fetch in-mem result first - assuming that'd be generally have small cardinality
and then use it to check against duplicate)
> Property index stored locally
> -----------------------------
>
> Key: OAK-4233
> URL: https://issues.apache.org/jira/browse/OAK-4233
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: documentmk, query
> Reporter: Tomek Rękawek
> Priority: Minor
> Fix For: 1.6
>
>
> When running Oak in a cluster, each write operation is expensive. After
> performing some stress-tests with a geo-distributed Mongo cluster, we've
> found out that updating property indexes is a large part of the overall
> traffic. Let's try to create a new property-local index, that will save the
> indexed data locally, without sharing it.
> Assumptions:
> -there's a new {{property-local}} index type for which the data are saved in
> the local SegmentNodeStore instance created specifically for this purpose,
> -local changes are indexed using a new editor, based on the
> {{PropertyIndexEditor}},
> -remote changes are extracted from the JournalEntries fetched in the
> background read operation and indexed as well,
> -the new index type won't support uniqueness restriction.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)