[
https://issues.apache.org/jira/browse/LUCENE-10140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17422822#comment-17422822
]
Alan Woodward commented on LUCENE-10140:
----------------------------------------
I wonder if we can be cleverer about rewriting ORDERED to pick out repeating
subiterators. Currently we notice if consecutive subiterators are equal and
rewrite them to a RepeatingIntervalIterator. We could try and add some logic
that rewrites ORDERED("a", "b", "a") to CONTAINS(REPEATING("a", 2), "b"), and
then caching would work correctly. It gets tricky quickly though.
> Minimizing intervals can give inaccurate positions for duplicate terms
> ----------------------------------------------------------------------
>
> Key: LUCENE-10140
> URL: https://issues.apache.org/jira/browse/LUCENE-10140
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/queries
> Reporter: Nikolay Khitrin
> Priority: Minor
>
> Minimizing intervals (maybe just ORDERED and AT_LEAST, but not sure) can move
> sub iterators to non-sub-match position *inside* match window, but
> CachingMatchesIterator logic relies on heuristic that any position inside
> matching interval is a sub-match.
> For example: ORDERED("a", "b", "a") over "a b a" highlights (report
> sub-matches) only "a <b>b</b> <b>a</b>", and ORDERED("a", "b", "a", "b", "a")
> highlights only "a b <b>a</b> <b>b</b> <b>a</b>".
> Looks like there is no way to determine the right moment to cache from
> caching iterator perspective, so I propose to add an interface allowing
> minimizing IntervalIterators notify sub-sources positioned at sub-match
> positions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
