[
https://issues.apache.org/jira/browse/SOLR-18550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Puneet Ahuja updated SOLR-18550:
--------------------------------
Description:
For a combined query, the coordinator reports {{numFound}} as the largest
sub-query's match count, not the distinct document count of the fused result.
Reported on [[email protected]|mailto:[email protected]] by Justin
Michael Coyne, verified on 10.1.0-rc2
Both symptoms are in {{{}CombinedQueryComponent.mergeIds{}}}:
* {{numFound = max(numFound, queryNumFound)}} keeps the larger list's count
(3) instead of the fused count (5).
* The exactness check is inverted: {{hitCountIsExact = hitCountIsExact &&
Boolean.FALSE.equals(docs.getNumFoundExact())}} makes an exact shard count
report as inexact and an inexact one stay exact.
{{QueryComponent.mergeIds}} has the correct form for comparison. The
{{numFound--}} in the queue-overflow branch is dead code, overwritten by the
max right after.
h2. Solution:
* Report {{numFound}} as the distinct number of fused documents.
* Set {{numFoundExact}} false when a sub-query list was truncated by the
fusion pool ({{{}shards.rows{}}}, {{{}start + rows{}}}, or knn {{{}topK{}}}),
and fix the conjunction.
* Remove the dead {{{}numFound--{}}}.
The feature shipped in 9.11.0 and 10.1.0, so both lines are affected.
Related: SOLR-17319 (the combined query feature). The fix is independent of
SOLR-18542 / [#5119|https://github.com/apache/solr/pull/5119], which only
touches ReciprocalRankFusion.
was:
h1. Combined Query Report
For a combined query, the coordinator reports \{{numFound}} as the largest
sub-query's match count, not the distinct document count of the fused result.
Reported on [[email protected]|mailto:[email protected]] by Justin
Michael Coyne, verified on 10.1.0-rc2
Both symptoms are in \{{CombinedQueryComponent.mergeIds}}:
* {\{numFound = max(numFound, queryNumFound)}} keeps the larger list's count
(3) instead of the fused count (5).
* The exactness check is inverted: \{{hitCountIsExact = hitCountIsExact &&
Boolean.FALSE.equals(docs.getNumFoundExact())}} makes an exact shard count
report as inexact and an inexact one stay exact.
{\{QueryComponent.mergeIds}} has the correct form for comparison. The
\{{numFound--}} in the queue-overflow branch is dead code, overwritten by the
max right after.
h2. Solution:
* Report \{{numFound}} as the distinct number of fused documents.
* Set \{{numFoundExact}} false when a sub-query list was truncated by the
fusion pool (\{{shards.rows}}, \{{start + rows}}, or knn \{{topK}}), and fix
the conjunction.
* Remove the dead \{{numFound--}}.
The feature shipped in 9.11.0 and 10.1.0, so both lines are affected.
Related: SOLR-17319 (the combined query feature). The fix is independent of
SOLR-18542 / [#5119|https://github.com/apache/solr/pull/5119], which only
touches ReciprocalRankFusion.
> Wrong numFound and numFoundExact for Combined Query results
> -----------------------------------------------------------
>
> Key: SOLR-18550
> URL: https://issues.apache.org/jira/browse/SOLR-18550
> Project: Solr
> Issue Type: Bug
> Affects Versions: 10.1, 9.11
> Reporter: Puneet Ahuja
> Priority: Major
>
> For a combined query, the coordinator reports {{numFound}} as the largest
> sub-query's match count, not the distinct document count of the fused result.
> Reported on [[email protected]|mailto:[email protected]] by Justin
> Michael Coyne, verified on 10.1.0-rc2
> Both symptoms are in {{{}CombinedQueryComponent.mergeIds{}}}:
> * {{numFound = max(numFound, queryNumFound)}} keeps the larger list's count
> (3) instead of the fused count (5).
> * The exactness check is inverted: {{hitCountIsExact = hitCountIsExact &&
> Boolean.FALSE.equals(docs.getNumFoundExact())}} makes an exact shard count
> report as inexact and an inexact one stay exact.
> {{QueryComponent.mergeIds}} has the correct form for comparison. The
> {{numFound--}} in the queue-overflow branch is dead code, overwritten by the
> max right after.
> h2. Solution:
> * Report {{numFound}} as the distinct number of fused documents.
> * Set {{numFoundExact}} false when a sub-query list was truncated by the
> fusion pool ({{{}shards.rows{}}}, {{{}start + rows{}}}, or knn {{{}topK{}}}),
> and fix the conjunction.
> * Remove the dead {{{}numFound--{}}}.
> The feature shipped in 9.11.0 and 10.1.0, so both lines are affected.
> Related: SOLR-17319 (the combined query feature). The fix is independent of
> SOLR-18542 / [#5119|https://github.com/apache/solr/pull/5119], which only
> touches ReciprocalRankFusion.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
