janhoy opened a new issue, #114: URL: https://github.com/apache/solr-orbit/issues/114
`SolrOptimize` defaults `max-segments` to `1` and always passes `maxSegments` to Solr, so every workload using the `optimize` operation force-merges the entire index down to a single segment. Modern Solr honours the merge policy's `maxSegmentSizeMB` when `maxSegments` is not supplied, merging down to as few segments as that ceiling allows. That is the better default here. A single enormous segment is a shape no production index would hold, so queries measured against it are measured against an index nobody runs; and reaching it costs a full rewrite of the index, which on a large corpus is the longest single operation in a benchmark run by a wide margin. The runner should forward `maxSegments` only when the workload explicitly sets it, letting Solr apply its own policy otherwise. Passing `max_segments` would still force the old behaviour for a workload that genuinely wants one segment. The matching workload-side change is apache/solr-orbit-workloads#22, which is already merged. Both halves are needed: with the template passing `1` unconditionally, the runner never sees an unset value. 🤖 Assisted by Claude Code -- 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]
