Adrien Grand

The use-case makes sense to me, but like @msokolov I'm worried that this could limit future implementations. For instance if we were to encode postings as a bitset, we wouldn't...

Thinking through this a bit more, I imagine that this is the reason why you made this API optional. We still like the set the bar quite high to add...

See discussion on [LUCENE-8739](https://issues.apache.org/jira/browse/LUCENE-8739), this PR is unlikely going to get merged.

Thanks for tackling this! Your are going in the right direction. Could we drop most of the `if (terms != Terms.EMPTY)` checks and handle them like any non-null `Terms` instance?

Thanks @shahrs87, could you now try to remove all instances of `if (terms == Terms.EMPTY)`? Hopefully existing logic should work with Terms instances regardless of whether they are empty or...

@shahrs87 Can you look into removing all other instances of `terms == Terms.EMPTY` or `terms != Terms.EMPTY` as well? To do this while keeping tests passing, I think you'll need...

FYI @gsmiller and I looked into using a FOR-like encoding for doc values at https://issues.apache.org/jira/browse/LUCENE-10033. In short, this made queries that look at most docs like the `Browse*` faceting tasks...

Why is it a performance bug, do we have scorers that are slow to do an `advance(NO_MORE_DOCS)`?

I worry that such a change would be adding little overhead all the time only to help in some rare cases, it's not clear to me that it would be...

Maybe another option would be to get rid of these threadlocals. We're relying less on them than we used too, e.g. doc values readers are no longer cached in threadlocals...