Adrien Grand

> Interesting point.. Thinking how/when we'd like to track the impact of temp output files. From what I understand, they won't be a part of commit and fsync. So if...

>> I'm considering exposing write amplification separately for flushes (as flushedBytes / totalIndexSize), merges (as (totalIndexSize + mergedBytes) / totalIndexSize) and temporary files (as (totalIndexSize + tempBytes) / totalIndexSize) and...

> Though since this does seem like it might be a point of confusion for users in that there are multiple ways to calculate this, do you think it would...

I merged your other PR that adds a null check in FieldExistsQuery, we should now be able to remove this null check with this change?

Test failures suggest CheckIndex needs to have its expectations adjusted.

We already have one class that wraps an `IndexReader` and an `Executor`: `IndexSearcher`. Should this new `rewrite` method take an `IndexSearcher` instead of an `IndexReader` and an `Executor`?

(and should it replace the existing rewrite method instead of just adding another one?)

I don't think it'd be weird to require an `IndexSearcher`, `Query#rewrite` is essentially a way to improve caching and keep `Query#createWeight` simple. Given that `Query#createWeight` already creates an `IndexSearcher`, I'd...

Agreed on making this Lucene 10. As far as bw compat is concerned, I was thinking of updating Lucene 9 this way: - introduce `Query#rewrite(IndexSearcher)` and make it delegate to...

> Of course in the case that somebody writes a subclass that only implements the IndexReader variant of rewrite it won't use the searcher. If this user subclass then rewrites...