[
https://issues.apache.org/jira/browse/SOLR-18550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18128692#comment-18128692
]
Puneet Ahuja commented on SOLR-18550:
-------------------------------------
PR [#5172|https://github.com/apache/solr/pull/5172] is updated per review and
handles:
* {{numFound}} no longer drops below the largest sub-query's match count, and
equals the distinct fused count when it can.
* {{numFoundExact}} is fixed — the count is marked inexact whenever a
sub-query list was truncated, instead of the inverted reporting earlier.
What remains on this issue:
* The exact distinct match count (the true union, like {{/select}} reports) —
computed per shard and summed at the coordinator, with the same handling in the
single-node path. The DocSet cost per sub-query needs to be weighed when this
is taken up.
> 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
> Labels: pull-request-available
> Time Spent: 50m
> Remaining Estimate: 0h
>
> 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]
