lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <>
Subject Re: add an "afterFilter" to
Date Fri, 25 Mar 2011 18:52:38 GMT

: 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...
      new BiasedWrapperMatcher(
        new BiasedWrapperMatcher(
      // other args to search


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message