[jira] [Commented] (LUCENE-9628) Make sure to account for ScoreMode.TOP_DOCS in queries
[
https://issues.apache.org/jira/browse/LUCENE-9628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17245343#comment-17245343
]
Mayya Sharipova commented on LUCENE-9628:
-
I've create a PR to address the discussed points.
There are other occurrences of checks of scoreMode in boolean scores that we
should probably improve to account for other score modes, but I don't know this
code well enough to make the change.
> Make sure to account for ScoreMode.TOP_DOCS in queries
> --
>
> Key: LUCENE-9628
> URL: https://issues.apache.org/jira/browse/LUCENE-9628
> Project: Lucene - Core
> Issue Type: Test
> Components: core/search
>Reporter: Julie Tibshirani
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I noticed a few places where we are directly check the {{ScoreMode}} type
> that should perhaps be generalized. These could affect whether numeric sort
> optimization is applied:
> * In {{BooleanWeight#bulkScorer}}, we check if score mode is {{TOP_SCORES}}
> and if so, force non-bulk scoring. Should we expand this to include modes
> like {{TOP_DOCS}}?
> * In {{ConstantScoreQuery}}, we create the delegate weight with a hardcoded
> {{COMPLETE_NO_SCORES}}. I'm not sure it actually causes problems, but it
> seems like this doesn't handle {{TOP_DOCS}} correctly.
> Apologies this issue isn’t more precise – I am not up-to-speed on the numeric
> sort optimization but wanted to raise these in case they’re helpful.
--
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
[jira] [Commented] (LUCENE-9628) Make sure to account for ScoreMode.TOP_DOCS in queries
[
https://issues.apache.org/jira/browse/LUCENE-9628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243576#comment-17243576
]
Julie Tibshirani commented on LUCENE-9628:
--
bq. I think it'd be helpful if we improved ScoreMode javadocs to be more
explicit regarding the expectations we have on scorers.
This would be great. Adding one last spot I noticed as it may be easy to cover
in a broader fix: {{DisjunctionScorer}} checks whether scores are required
through {{scoreMode != ScoreMode.COMPLETE_NO_SCORES}}, which could just be
{{scoreMode.needsScores()}} now.
> Make sure to account for ScoreMode.TOP_DOCS in queries
> --
>
> Key: LUCENE-9628
> URL: https://issues.apache.org/jira/browse/LUCENE-9628
> Project: Lucene - Core
> Issue Type: Test
> Components: core/search
>Reporter: Julie Tibshirani
>Priority: Minor
>
> I noticed a few places where we are directly check the {{ScoreMode}} type
> that should perhaps be generalized. These could affect whether numeric sort
> optimization is applied:
> * In {{BooleanWeight#bulkScorer}}, we check if score mode is {{TOP_SCORES}}
> and if so, force non-bulk scoring. Should we expand this to include modes
> like {{TOP_DOCS}}?
> * In {{ConstantScoreQuery}}, we create the delegate weight with a hardcoded
> {{COMPLETE_NO_SCORES}}. I'm not sure it actually causes problems, but it
> seems like this doesn't handle {{TOP_DOCS}} correctly.
> Apologies this issue isn’t more precise – I am not up-to-speed on the numeric
> sort optimization but wanted to raise these in case they’re helpful.
--
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
[jira] [Commented] (LUCENE-9628) Make sure to account for ScoreMode.TOP_DOCS in queries
[
https://issues.apache.org/jira/browse/LUCENE-9628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243150#comment-17243150
]
Mayya Sharipova commented on LUCENE-9628:
-
[~jtibshirani] Thank you for raising these very good issues.
I agree with you and [~jpountz] about switching to a check of
`ScoreMode#isExhaustive == false` instead of just `scoreMode ==
ScoreMode.TOP_SCORES` in `BooleanWeight`. I will address this.
---
About `ConstantScoreQuery`:
* I will see how we can addressed `TOP_DOCS` case as well without using
`COMPLETE_NO_SCORES` for `innerWeight` all the time.
* agree with [~jpountz] that we can improve javadoc of `ScoreMode`
> Make sure to account for ScoreMode.TOP_DOCS in queries
> --
>
> Key: LUCENE-9628
> URL: https://issues.apache.org/jira/browse/LUCENE-9628
> Project: Lucene - Core
> Issue Type: Test
> Components: core/search
>Reporter: Julie Tibshirani
>Priority: Minor
>
> I noticed a few places where we are directly check the {{ScoreMode}} type
> that should perhaps be generalized. These could affect whether numeric sort
> optimization is applied:
> * In {{BooleanWeight#bulkScorer}}, we check if score mode is {{TOP_SCORES}}
> and if so, force non-bulk scoring. Should we expand this to include modes
> like {{TOP_DOCS}}?
> * In {{ConstantScoreQuery}}, we create the delegate weight with a hardcoded
> {{COMPLETE_NO_SCORES}}. I'm not sure it actually causes problems, but it
> seems like this doesn't handle {{TOP_DOCS}} correctly.
> Apologies this issue isn’t more precise – I am not up-to-speed on the numeric
> sort optimization but wanted to raise these in case they’re helpful.
--
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
[jira] [Commented] (LUCENE-9628) Make sure to account for ScoreMode.TOP_DOCS in queries
[
https://issues.apache.org/jira/browse/LUCENE-9628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17242585#comment-17242585
]
Adrien Grand commented on LUCENE-9628:
--
bq. In BooleanWeight#bulkScorer, we check if score mode is TOP_SCORES and if
so, force non-bulk scoring. Should we expand this to include modes like
TOP_DOCS?
I think so. DefaultBulkScorer seems to be the only bulk scorer which knows how
to deal with {{LeafCollector#competitiveIterator}}, so we seem to be disabling
the numeric sort optimization with boolean queries today? Let's switch to
ScoreMode#isExhaustive? What do you think [~mayyas]?
bq. In ConstantScoreQuery, we create the delegate weight with a hardcoded
COMPLETE_NO_SCORES. I'm not sure it actually causes problems, but it seems like
this doesn't handle TOP_DOCS correctly.
I suspect that this could be a problem if the wrapped query uses the ScoreMode
as an indication of whether it will need to handle
{{LeafCollector#competitiveIterator}} or not, which seems to be something we'd
like to do for boolean queries since BS1 (BooleanScorer) only really makes
sense if we know we're going to collect all matches.
I think it'd be helpful if we improved ScoreMode javadocs to be more explicit
regarding the expectations we have on scorers. TOP_SCORES mentions the
relationship with {{Scorer#setMinCompetitiveScore}}, we should add something
similar to TOP_DOCS and TOP_DOCS_WITH_SCORES regarding bulk scorers and
{{LeafCollector#competitiveIterator}}?
> Make sure to account for ScoreMode.TOP_DOCS in queries
> --
>
> Key: LUCENE-9628
> URL: https://issues.apache.org/jira/browse/LUCENE-9628
> Project: Lucene - Core
> Issue Type: Test
> Components: core/search
>Reporter: Julie Tibshirani
>Priority: Minor
>
> I noticed a few places where we are directly check the {{ScoreMode}} type
> that should perhaps be generalized. These could affect whether numeric sort
> optimization is applied:
> * In {{BooleanWeight#bulkScorer}}, we check if score mode is {{TOP_SCORES}}
> and if so, force non-bulk scoring. Should we expand this to include modes
> like {{TOP_DOCS}}?
> * In {{ConstantScoreQuery}}, we create the delegate weight with a hardcoded
> {{COMPLETE_NO_SCORES}}. I'm not sure it actually causes problems, but it
> seems like this doesn't handle {{TOP_DOCS}} correctly.
> Apologies this issue isn’t more precise – I am not up-to-speed on the numeric
> sort optimization but wanted to raise these in case they’re helpful.
--
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
