[
https://issues.apache.org/jira/browse/OAK-1654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13956460#comment-13956460
]
Alex Parvulescu commented on OAK-1654:
--------------------------------------
bq. Still, it's possible to do it more lazily and possibly conserve memory
(read until there is a match, instead of fully read both in every case; only
keep entries in memory of one side).
There can be _n_ cursors not just 2, and just reading one and traversing all of
the others from the beginning to a potential match seems like a lot of
inefficient work. You cannot guarantee that you use the smallest of the sets as
a reference or that the sets are ordered by path, so the worst case scenario is
really bad.
But I agree that this part needs some more work.
bq. The bigger problem is that reading the paths only breaks jcr:score().
right, I'll update the patch to include the score.
> Composite index aggregates
> --------------------------
>
> Key: OAK-1654
> URL: https://issues.apache.org/jira/browse/OAK-1654
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: oak-lucene, query
> Reporter: Alex Parvulescu
> Assignee: Alex Parvulescu
> Fix For: 0.20
>
> Attachments: OAK-1654.patch
>
>
> This is a followup for what is still missing from OAK-828: composite
> aggregates.
> This covers 2 parts:
> - when searching for 2 tokens that can be present on 2 different nodes, the
> common aggregated parent doesn't show up
> - when adding together multiple contains clauses on different hierarchy
> levels: now the lucene index simply returns an infinite cost.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
