Hi Amrit, Thanks for the coordination. The overlap is really one line — the inverted numFoundExact fold in mergeIds. The rest is complementary: #5117 fixes the merge totals, #5172 fixes the count semantics. Sonu has suggested #5172 merges first with #5117 rebasing on top. Your pool-size concern was right and is fixed: #5172 now reports numFound = max(largest sub-query's count, distinct fused count), inexact under truncation — so your 1000-hits example still reports ~1000.
I'll keep driving the union-count follow-up on SOLR-18550, and your help on the shard side is welcome. Puneet On Sat, Oct 17, 2026 at 8:28 AM Amrit Sarkar <[email protected]> wrote: > Hi Puneet, Justin, > > This one is already tracked in SOLR-18541 (Nick Shanin, PR #5117). I > reproduced Justin's report on the RC2 tarball last night and posted the > details there: > > https://www.google.com/url?q=https://issues.apache.org/jira/browse/SOLR-18541?focusedCommentId%3D18127698%23comment-18127698&source=gmail&ust=1792292324548000&sa=E > > Nick has since updated #5117 so numFoundExact is false whenever more than > one sub-query contributes, and asked for the union count as a follow-up, > which I'd offered to take. SOLR-18550 covers the same ground, and #5117 and > #5172 change the same exactness line in mergeIds, so let's pick one home > and link the other. > > One concern with #5172: numFound becomes the size of the fused pool. Once > a sub-query has more matches than start+rows (or shards.rows), that's well > below what we report today. A query with 1000 hits at rows=10 would go from > numFound=1000 to about 20, so a paging UI shows 2 pages. It's marked > inexact, but it's still a step back for the common case. > > An exact count is doable. Shards don't share docs, so each shard can > report its own union count (simpleCombine already builds that DocSet union > when faceting is on) and the coordinator sums them. That matches /select. > The cost is a DocSet per sub-query on every combined request, which a > maintainer should weigh in on. > > Happy to work on this together. Puneet, if you want to keep driving it on > SOLR-18550, I'll review and help with the shard side. Otherwise I'll pick > it up as the follow-up Nick suggested. > > Amrit > > On Fri, Oct 16, 2026 05:36 AM, Puneet Ahuja <[email protected]> > wrote: > >> Hi Justin, >> >> Thanks for the writeup. I actually ran into the same bug a few days back >> while working on the RRF weights change ( >> https://github.com/apache/solr/pull/5119), so this was on my list to fix >> anyway. >> >> The cause is in CombinedQueryComponent.mergeIds: numFound ends up as the >> bigger sub-query's count instead of the fused one, and the numFoundExact >> check is inverted, which is why your all-exact example shows false. >> >> I have filed a JIRA(https://issues.apache.org/jira/browse/SOLR-18550) and >> will raise a PR on main with the fix shortly. Your repro would make a good >> test case, so I'll fold it in. Happy to review with you or have you review >> the patch. I've credited you as the reporter in the JIRA and the >> changelog. >> >> >> Puneet >> >> On Fri, Oct 16, 2026 at 2:28 AM Justin Michael Coyne via dev < >> [email protected]> wrote: >> >> > I was working with CombinedQuerySearchHandler (in solr 10.1.0.rc2) today >> > and noticed that it reports numFound as the largest sub-query's hit >> count, >> > not the size of the fused result. Shouldn't it instead be the number of >> > distinct documents in the combined result, which is the union of the >> > sub-queries? >> > >> > Here's a reproduction: >> > >> > SOLR=http://localhost:8983/solr/demo >> > >> > curl -s "$SOLR/config" -H 'Content-Type: application/json' -d '{ >> > "add-searchcomponent": {"name": "combined_query", "class": >> > "solr.CombinedQueryComponent"}, >> > "add-requesthandler": {"name": "/hybrid", "class": >> > "solr.CombinedQuerySearchHandler"} >> > }' >> > 3 cat docs, 2 dog docs, no overlap >> > curl -s "$SOLR/update?commit=true" -H 'Content-Type: application/json' >> -d >> > '[ >> > {"id": "1", "subject_s": "cat"}, >> > {"id": "2", "subject_s": "cat"}, >> > {"id": "3", "subject_s": "cat"}, >> > {"id": "4", "subject_s": "dog"}, >> > {"id": "5", "subject_s": "dog"} >> > ]' >> > >> > >> > curl -s "$SOLR/hybrid" -H 'Content-Type: application/json' -d '{ >> > "queries": { >> > "cats": {"lucene": {"query": "subject_s:cat"}}, >> > "dogs": {"lucene": {"query": "subject_s:dog"}} >> > }, >> > "params": { >> > "combiner": true, >> > "combiner.query": ["cats", "dogs"], >> > "combiner.algorithm": "rrf", >> > "fl": "id", >> > "rows": 10 >> > } >> > }' >> > >> > >> > Expected >> > `numFound: 5`, the same as `/select?q=subject_s:cat OR subject_s:dog`, >> > which returns `numFound: 5, numFoundExact: true`. >> > Actual >> > {"response": {"numFound": 3, "start": 0, "numFoundExact": false, >> > "docs": [{"id": "4"}, {"id": "1"}, {"id": "5"}, {"id": "2"}, {"id": >> "3"}]}} >> > >> > The response returns five documents but reports `numFound: 3`. >> > >> >
