jimczi commented on code in PR #16847:
URL: https://github.com/apache/lucene/pull/16847#discussion_r4312744029
##########
lucene/core/src/java/org/apache/lucene/index/IndexReader.java:
##########
@@ -294,22 +294,25 @@ public final int hashCode() {
*
* <p><b>NOTE</b>: This operation may run in O(maxDoc). Implementations that
can't return this
* number in constant-time should cache it.
+ *
+ * <p>Access the per-segment {@code int} count with {@link
LeafReader#numLeafDocs()}.
*/
- public abstract int numDocs();
+ public abstract long numDocs();
Review Comment:
Yeah agreed, it needs the same treatment as maxDoc and numDocs. We can apply
the same idea there too. I just put up a commit for it.
`docFreq(Term)` and `getDocCount(String)` return `long` on `IndexReader`
now, since across a composite reader they can go past an int. The per-segment
counts stay int, you get them from `leafDocFreq()` and `getLeafDocCount()` on
`LeafReader`.
The `TermStats` and `FieldStats` records were already long so I missed that
the feeders were still int. `TermStates` now accumulates docFreq as a long and
`IndexSearcher.termStats` takes a long. There was also a silent overflow in the
static `PointValues.getDocCount(reader, field)` helper that sums across leaves,
so that one returns long now. The per-segment `getDocCount()` stays int.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
