Robert Muir

That's an actual veto. justification: read the fucking mailing list thread, see how @janhoy tried to "slip this in" under the pretense of a +1. Several of us are against...

I'm concerned about this change: other things will overflow if you have too many term frequencies in a field. Currently frequency is bounded by 2^32-1 within a doc, and you...

`totalTermFreq`/`sumTotalTermFreq` are about term frequencies, nothing to do with the norms... but this norms check is the only thing guarding against overflow. we can't just disable the check like this...

>> Hmm, but I think sumTotalTermFreq, which is per field sum of all totalTermFreq across all terms in that field, could overflow long even today, in and adversarial case. And...

> How about decoupling these two problems? First, let's fix the aggregation of totalTermFreq and sumTotalTermFreq to explicitly catch any overflow instead of just doing the dangerous += today: https://github.com/apache/lucene-solr/blob/master/lucene/core/src/java/org/apache/lucene/codecs/PushPostingsWriterBase.java#L142...

can the optimization be implemented in a less-invasive manner?

maybe the better approach is top-down: for example starting at high level sorting/faceting algorithms, do they really go through any trouble to resolve ordinals in sequential order or do they...

Sorry, I'm against this change. The test is broken. It looks like we are willing to make bad tradeoffs in order to deliver CorruptIndexException and only CorruptIndexException if anything goes...

Nice improvement here. I think we should not let the stacktrace stuff be a blocker for this optimization. Out of box, the user should never even see exceptions anyway: the...

I'm -1 to this approach because it breaks the use of the OS cache (I stated this on the JIRA issue, it was ignored, I don't want anyone to forget)....