PSeitz

> > I think we would need a benchmark to justify the additional code. > > FWIW: The benchmarks that I did in ParadeDB for this PR are over here:...

> Why is this an improvement? > > It is `Option` vs `EnumWithDocIdVariant` isn't it? The `Option` is just the consequence, when we remove the unused `SortingFieldExtractorComponent::DocId`. But it seems...

I'd rather have the limitation that both bounds provided by the user have to be of the same type and otherwise return an error Not sure it makes sense to...

> > I'd rather have the limitation that both bounds provided by the user have to be of the same type and otherwise return an error > > Not sure...

> Hi @PSeitz PTAL, I re-implemented this part of the code, converting `lower_bound` and `upper_bound` to `actual_column_type` respectively I'd rather have the limitation that both bounds provided by the user...

I opened a PR with a fix: https://github.com/yetone/avante.nvim/pull/1819

It's broken again after the revert: https://github.com/yetone/avante.nvim/pull/1839

I think this is similar to what I wrote here recently https://github.com/quickwit-oss/tantivy/issues/2352#issuecomment-2067577027 : > I've been thinking if we should flag fast fields as almost sorted during creation (e.g. almost...

### Analysis - Request dispatch The flamegraph is the first peak when dispatching the requests, but before the collection. It's the second request, so caches should be filled. The request...

`async fn leaf_search` is indeed really big with 4kb per instance. This cost is exacerbated by the main problem: we currently create `num index * num splits ` leaf search...