[
https://issues.apache.org/jira/browse/LUCENE-4100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13833573#comment-13833573
]
Stefan Pohl commented on LUCENE-4100:
-------------------------------------
Thanks for your interest, [~daubman].
[~rcmuir] accurately describes the current status and challenges here. There
have to be made quite a few major and even more minor steps to eventually
arrive at anything general-purpose and user-ready.
However, given the feedback that I got so far (there seem to be many people
that don't have extremely high NRT-requirements and who rebuild their whole
indexes every few hours/days anyways), I still think that it would be
worthwhile to have this as-is (with the limitation to static indexes) in a
separate contrib-package that users are discouraged to use, except they really
know what they are doing. Adding a few exceptions to guard users from wrong
behaviour/misusage might also be useful.
As long as I, as the reporter, don't close the issue, it won't 'bite rot',
don't worry ;) I also got to hear of quite some interest when I mentioned it at
this year's Lucene/Solr-Revolutions.EU conference.
> Maxscore - Efficient Scoring
> ----------------------------
>
> Key: LUCENE-4100
> URL: https://issues.apache.org/jira/browse/LUCENE-4100
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/codecs, core/query/scoring, core/search
> Affects Versions: 4.0-ALPHA
> Reporter: Stefan Pohl
> Labels: api-change, patch, performance
> Fix For: 4.7
>
> Attachments: contrib_maxscore.tgz, maxscore.patch
>
>
> At Berlin Buzzwords 2012, I will be presenting 'maxscore', an efficient
> algorithm first published in the IR domain in 1995 by H. Turtle & J. Flood,
> that I find deserves more attention among Lucene users (and developers).
> I implemented a proof of concept and did some performance measurements with
> example queries and lucenebench, the package of Mike McCandless, resulting in
> very significant speedups.
> This ticket is to get started the discussion on including the implementation
> into Lucene's codebase. Because the technique requires awareness about it
> from the Lucene user/developer, it seems best to become a contrib/module
> package so that it consciously can be chosen to be used.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
