bugfix (Solr 10.x port): Performance degradation for collapse queries with string sort clauses due to enforced LZ4 decompression

[bartoszfidrysiak]

https://issues.apache.org/jira/browse/SOLR-XXXXX (not yet created)

Related PRs:

• bugfix (Solr 9.x port): Performance degradation for collapse queries with string sort clauses due to enforced LZ4 decompression #4618

Description

Migrating to Lucene90DocValuesProducer in Solr 9 revealed a significant performance regression in collapse queries sorted by string fields, due to the extra overhead of LZ4 decompression. Solr 9’s collapse implementation does not apply any optimizations and always calls Lucene’s TermOrdValLeafComparator.copy(), which triggers LZ4.decompress() for every document processed by the collapse query. This decompression overhead did not exist in Solr 8.

SortFieldsCompare.testAndSetGroupValues() / setGroupValues()
  → TermOrdValLeafComparator.copy()
    → BaseSortedDocValues.lookupOrd()
      → TermsDict.seekExact()
        → TermsDict.decompressBlock()
          → LZ4.decompress()   ← bottleneck

Solution

This PR proposes two improvements:

1. Load string-sorted doc values lazily for group heads, materializing the string only when a competing document appears.
2. Avoid loading or materializing string-sorted doc values for documents in the same segment during collapse. Use ordinals instead - they’re numeric, cheaper to compare, and don’t need decompression.

The first improvement focuses on scenarios where many collapse groups contain only a single document, or where collapse sorting uses multiple fields with a string field acting as a tie-breaker.

The second improvement is expected to deliver major gains in cases where many documents originate from the same segment.

Tests

Four new tests were added in TestCollapseQParserPlugin:

• testCollapseStringSortLazyLoadingTieDoesNotEvictGroupHead - verifies that when two documents in the same group have an equal string sort value, the first-seen document remains the group head (a tie must not trigger eviction). Covers both single-segment (ordinal fast path) and multi-segment (slow path) cases.
• testCollapseStringSortOrdinalFastPathMultiClauseTieBreaking - verifies that when clause-1 of a multi-clause sort ties on ordinal comparison, clause-2 correctly decides the winner. Also exercises the remaining-values copy loop with a cross-segment competitor.
• testCollapseStringSortWithoutDocValuesSkipsLazyLoadingAndOrdinalFastPath- verifies that sorting on a string field without SORTED DocValues produces correct results via the eager field-comparator path, ensuring the lazy loading and ordinal fast path are safely bypassed when unavailable.
• testCollapseStringSortOrdinalFastPathDescendingWithMissingValues - verifies that missing values rank last even under a descending sort, where the missing-value sentinel (missingOrd = -1) combined with reverseMul = -1 must still produce the correct ordering in the ordinal fast path.

In addition to TestCollapseQParserPlugin, the CollapsingSearch benchmark was introduced to compare average execution times for collapse queries across different sort field combinations. In the benchmark, documents from the same groups are distributed evenly across all segments. The benchmark was executed locally on my machine against Solr branch 10.x and Solr branch 10.x-SNAPSHOT, which includes the enhancements.

Conclusions:

• The collapseByDateAndStr benchmark shows that Solr 10 SNAPSHOT performs significantly better regardless of the number of segments. This is because the string field serves only as a tiebreaker in the collapse sort, so in most cases comparing dates is sufficient to determine the winner. In addition, string doc values are loaded lazily, which avoids eagerly materializing the string value when it is not needed. According to the benchmark data, the snapshot with the two improvements made collapseByDateAndStr about 7 times faster.
• The collapseByStr benchmark shows that Solr 10 SNAPSHOT delivers significantly better performance only when the number of segments is small, especially when most documents from the same group are located in the same segment. In the single-segment case, string doc values do not need to be materialized to pick a winner, since comparing element ordinals is enough and is both safe and efficient. According to the benchmark data, these two improvements together made collapseByStr about 38 times faster for one segment. With many segments, however, and with documents from the same groups spread evenly across them, the ordinal fast path provides no benefit because most comparisons still require string materialization.

Checklist

Please review the following and check all that apply:

• I have reviewed the guidelines for How to Contribute and my code conforms to the standards described there to the best of my ability.
• I have created a Jira issue and added the issue ID to my pull request title.
• I have given Solr maintainers access to contribute to my PR branch. (optional but recommended, not available for branches on forks living under an organisation)
• I have developed this patch against the main branch.
• I have run ./gradlew check.
• I have added tests for my changes.
• I have added documentation for the Reference Guide
• I have added a changelog entry for my change

[dsmiley]

Hello! Normally, contributions only go to main, the default branch, and then it's the committer's job to back-port to appropriate branches. I see you created 2 PRs, neither to the correct branch. That said... I suppose this one will do and I'll port up. I recommend closing the 9x one unless you think there are non-trivial details in there. I'm trying to sollicit a better reviewer but I may end up being the one.

[dsmiley]

I filed https://issues.apache.org/jira/browse/SOLR-18304 and with Claude Opus did a little bit of research pointing to Lucene 8.9.0 which is when this term dictionary compression was introduced, which is likely when it would first impact Solr users. Wow... been a long time if true!

[bartoszfidrysiak]

@dsmiley
Let me create PR to the main branch and close for now the others.

[bartoszfidrysiak]

@dsmiley
I created #4621 and closed PRs for ports.

[bartoszfidrysiak]

Closing for now. According #4620 (comment), we should first create PR to main so I created #4621.