[
https://issues.apache.org/jira/browse/LUCENE-4396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14063089#comment-14063089
]
Da Huang edited comment on LUCENE-4396 at 7/16/14 3:53 AM:
-----------------------------------------------------------
Thank you, Mike!
{quote}
It looks like this gave some nice gains with the many-not cases
{quote}
Yes, but many-not cases might not be a usual case. Therefore, this method might
not be used in the final method.
{quote}
Curiously some of the tasks are really hurt by the larger sizes ... maybe 1<<9
is a good compromise?
{quote}
Yeah. Finally, I will just focus on those \*Some\* cases.
"size9" is better for HighAndSomeHighOr case, while "size5" is better for
LowAndSomeHighOr, LowAndSomeLowNot and LowAndSomeLowOr cases.
I think it would be better to detect the case type and adjust the SIZE of
bucketTable in BNS's constructor.
was (Author: dhuang):
Thank you, Mike!
{quote}
It looks like this gave some nice gains with the many-not cases
{quote}
Yes, but many-not cases may not be a usual case. Therefore, this method might
be used in the final method.
{quote}
Curiously some of the tasks are really hurt by the larger sizes ... maybe 1<<9
is a good compromise?
{quote}
Yeah. Finally, I will just focus on those \*Some\* cases.
"size9" is better for HighAndSomeHighOr case, while "size5" is better for
LowAndSomeHighOr, LowAndSomeLowNot and LowAndSomeLowOr cases.
I think it would be better to detect the case type and adjust the SIZE of
bucketTable in BNS's constructor.
> BooleanScorer should sometimes be used for MUST clauses
> -------------------------------------------------------
>
> Key: LUCENE-4396
> URL: https://issues.apache.org/jira/browse/LUCENE-4396
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Michael McCandless
> Attachments: And.tasks, AndOr.tasks, AndOr.tasks, LUCENE-4396.patch,
> LUCENE-4396.patch, LUCENE-4396.patch, LUCENE-4396.patch, LUCENE-4396.patch,
> LUCENE-4396.patch, LUCENE-4396.patch, LUCENE-4396.patch, LUCENE-4396.patch,
> SIZE.perf, luceneutil-score-equal.patch, luceneutil-score-equal.patch,
> stat.cpp
>
>
> Today we only use BooleanScorer if the query consists of SHOULD and MUST_NOT.
> If there is one or more MUST clauses we always use BooleanScorer2.
> But I suspect that unless the MUST clauses have very low hit count compared
> to the other clauses, that BooleanScorer would perform better than
> BooleanScorer2. BooleanScorer still has some vestiges from when it used to
> handle MUST so it shouldn't be hard to bring back this capability ... I think
> the challenging part might be the heuristics on when to use which (likely we
> would have to use firstDocID as proxy for total hit count).
> Likely we should also have BooleanScorer sometimes use .advance() on the subs
> in this case, eg if suddenly the MUST clause skips 1000000 docs then you want
> to .advance() all the SHOULD clauses.
> I won't have near term time to work on this so feel free to take it if you
> are inspired!
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
