Puneet Ahuja created SOLR-18550:
-----------------------------------
Summary: 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: 9.11, 10.1
Reporter: Puneet Ahuja
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.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
