tlrx opened a new issue, #16845: URL: https://github.com/apache/lucene/issues/16845
### Description Today a merged segment warmer (`IndexWriter.IndexReaderWarmer` set using `IndexWriterConfig#setMergedSegmentWarmer`) runs synchronously on the merge thread, right before the writer publishes the new segment. The merge thread stays blocked for the whole duration of warming. I use a warmer very much like the one in the replicator package (`PreCopyMergedSegmentWarmer`): it opens a reader on the freshly merged segment and does real work on it before that segment becomes visible. In my case warming isn't cheap and while it runs the merge thread is pinned doing no merge related work. So other pending merges queue up behind it even though the heavy `mergeMiddle` work for that merge is already done. I'd like to propose making warming optionally asynchronous. The merge thread would finish writing the merge, hand the warming off, and immediately be free to pick up the next merge. Warming would happen in the background; the merged segment simply wouldn't be published until the warming completes. The default can stay synchronous so nothing changes unless you opt in. I think it's worth it: the merge threads are released as soon as the merge is written so warming no longer inteferes with merges throughput. The warming cost (loading structures, pre-copying to replicas, whatever the warmer does) is removed off the critical merge path. Anecdotally, this would also compound better with something like #16571 (letting a single merge write more than one output segment) since more outputs per merge means more readers to warm per merge, so keeping warming off the merge thread matters even more there. I took a stab at it in #TBD for those who would like to see how it could look. The exception handling is the hard part because once warming runs in the background there's no caller left to rethrow to. But it turned out less messy than I expected, mostly because warming happens at the very end after the bulk of the merge work is already done and on disk. I think the publish/commit step can simply run on the warmer thread once warming succeeds. And since a merge that's still warming is kept in the IndexWriter's "running" set the shutdown semantics seem to hold up (ie, waitForMerges()/close()/rollback() would already block until warming is done). -- 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]
