[
https://issues.apache.org/jira/browse/LUCENE-5809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14057411#comment-14057411
]
Robert Muir commented on LUCENE-5809:
-------------------------------------
Thanks Mike: it looks all within noise to me. Its kinda sad luceneutil doesn't
show the leapfrog bug though. Maybe its partially because we only use two term
phrases. As the number of terms increase, wrong leapfrogging has a higher
impact I think. Maybe another reason is the phrase selection is based on how
common the phrase is, but doesnt have good enough variety (like rare phrase but
high frequency terms).
Anyway I think this is good to go, unless you have concerns.
> Simplify ExactPhraseScorer
> --------------------------
>
> Key: LUCENE-5809
> URL: https://issues.apache.org/jira/browse/LUCENE-5809
> Project: Lucene - Core
> Issue Type: Task
> Components: core/search
> Reporter: Robert Muir
> Attachments: LUCENE-5809.patch
>
>
> While looking at this scorer i see a few little things which are remnants of
> the past:
> * crazy heuristics to use next() over advance(): I think it should just use
> advance(), like conjunctionscorer. these days advance() isnt stupid anymore
> * incorrect leapfrogging. the lead scorer is never advanced if a subsequent
> scorer goes past it, it just falls into this nextDoc() loop.
> * pre-next()'ing: we are using cost() api to sort, so there is no need to do
> that.
> * UnionDocsAndPositionsEnum doesnt follow docsenum contract and set initial
> doc to -1
> * postingsreader advance() doesnt need to check docFreq > BLOCK_SIZE on each
> advance call, thats easy to remove.
> So I think really this scorer should just look like "conjunctionscorer that
> verifies positions on match".
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
