> And then we could make an IndexOrDocValuesQuery with both the TermInSetQuery and this SDV.newSlowInSetQuery?
Unfortunately IndexOrDocValuesQuery relies on the fact that the "index" query can evaluate its cost (ScorerSupplier#cost) without doing anything costly, which isn't the case for TermInSetQuery. So we'd need to make some changes. Estimating the cost of a TermInSetQuery in general without seeking the terms is a hard problem, but maybe we could specialize the unique key case to return the number of terms as the cost? On Tue, Oct 26, 2021 at 5:37 PM Robert Muir <rcm...@gmail.com> wrote: > On Tue, Oct 26, 2021 at 11:24 AM Robert Muir <rcm...@gmail.com> wrote: > > > > On Tue, Oct 26, 2021 at 10:58 AM Alan Woodward <romseyg...@gmail.com> > wrote: > > > > > > We have SortedSetDocValuesField.newSlowRangeQuery() which does > something close to what you want here, I think. > > > > > > > See also DocValuesRewriteMethod which might be useful, at least as a > > start. You'd have to express the "SetQuery" as a MultiTermQuery for > > that to work, but It would be more efficient than a disjunction of > > slow-exact-queries. > > Maybe that's the issue here? If TermInSetQuery extended > MultiTermQuery, then this would be trivial, you wouldn't have to write > any code to use the DV ordinals instead of the terms+postings, you'd > just call .setRewriteMethod(). > > Could/should TermInSetQuery be refactored to extend multitermquery? > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > -- Adrien
