[
https://issues.apache.org/jira/browse/LUCENE-4312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16883103#comment-16883103
]
Michael Gibney commented on LUCENE-4312:
----------------------------------------
That PR looks like a good start, [~romseygeek].
I'd still like to have a better sense of what bar we're trying to clear as far
as demonstrating the usefulness of recording position length in the index. It
seems we have consensus (basically unchanged since August of 2012), that:
# Recording position length in the index is relatively straightforward,
whether done via codecs and modified postings API or via Payloads and custom
Intervals/Spans implementations.
# Performant positional query implementation leveraging position length is a
significant challenge.
Would people be comfortable evaluating usefulness/performance based on the
Spans implementation proposed for LUCENE-7398, as opposed to holding out for an
Intervals query implementation? Particularly if we're talking proof-of-concept,
all of the performance implications are directly comparable (between Spans and
Intervals).
Is there a _conditional_ consensus that indexed position length would be a
worthwhile feature, assuming the implementation of performant positional
queries to leverage it?
> Index format to store position length per position
> --------------------------------------------------
>
> Key: LUCENE-4312
> URL: https://issues.apache.org/jira/browse/LUCENE-4312
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/codecs
> Affects Versions: 6.0
> Reporter: Gang Luo
> Priority: Minor
> Labels: Suggestion
> Original Estimate: 72h
> Remaining Estimate: 72h
>
> Mike Mccandless said:TokenStreams are actually graphs.
> Indexer ignores PositionLengthAttribute.Need change the index format (and
> Codec APIs) to store an additional int position length per position.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
