: After a match, we always skip on the filter first.
...
: > What's the use case behind this...?
:
: Optimizing cases where filters might be more expensive than the main query ;-)
I've lost track of what happened to the proposal of unifying "Filter" and
"Query" under an common "Matcher" API, but assuming such a transition
ultimately happened, then it seems like the ideal API would just take in a
single "Matcher" and some specific implementations of that API that wrap
other lists of Matchers could be used by the code in the cases where it
knows specific things about the performance of the matchers it wraps.
FairWrapperMatcher(List<Matcher>) could implement the basic logic of
always looping over the Matchers equally and advancing them each until
they coallesce on the same doc.
BiasedWrapperMatcher(Matcher,Matcher) could always advance the first
matcher before advancing the second -- for use cases where you know the
second one is more expensive then the first.
the idea of a "beforeFilter" that's cheap, a Query, and an
"afterFilter" that's expensive would be something like...
indexSearcher.search(
new BiasedWrapperMatcher(
cheapBeforeFilter,
new BiasedWrapperMatcher(
theQuery,
expensiveAfterFilter)),
// other args to search
);
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
