support multiple modes of execution for fastfield range query
in quickwit, we found that some query are faster when range queries are done through the ast, using fastfield-based range query, but some others prefer post filtering done inside the collector. This hints toward implementing two forms of fastfield-based range query, the current one when the range is very selective, and the "more naive filtering" when the range isn't very selective. The selection would also depend on how costly the rest of the query is, costlier queries tends to favor the currently present query, while cheaper queries seems to prefer filtering
I suspect that this optimization is potentially more broad?
During intersection, any time one clause of a BooleanQuery is more expensive to execute than the others, and the cheapest clauses end up with very few matches, then rather than doing a block-based intersection (where you fetch blocks of docids from each clause and then intersect them), then it might make sense to do a value-by-value intersection.
Ah... so this might be a dupe of #2531?
Yes, I think this should be mostly covered by having cost + seek_exact on the DocSet from https://github.com/quickwit-oss/tantivy/issues/2531
What it does not cover is to change the whole execution order, which would be equivalent to post filtering.