Re: add an "afterFilter" to IndexSearcher.search()

2011-03-28 Thread Chris Hostetter
: > Optimizing cases where filters might be more expensive than the main query ;-) : But you must have a real use case... that inspired this idea? Where : are apps/Solr "typically" using such expensive filters? i have no idea what usecase prompted yonik to start thinking about this, but the f

Re: add an "afterFilter" to IndexSearcher.search()

2011-03-26 Thread Michael McCandless
On Fri, Mar 25, 2011 at 2:33 PM, Yonik Seeley wrote: >>> Currently, supplying a filter to IndexSearcher.search() assumes that >>> it's cheaper to run than the main query. >> >> Wait, where do we assume that? > > After a match, we always skip on the filter first. Well, we next() on the filter, an

Re: add an "afterFilter" to IndexSearcher.search()

2011-03-25 Thread Marvin Humphrey
On Fri, Mar 25, 2011 at 11:52:38AM -0700, Chris Hostetter wrote: > > : 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 ha

Re: add an "afterFilter" to IndexSearcher.search()

2011-03-25 Thread Chris Hostetter
: 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"

Re: add an "afterFilter" to IndexSearcher.search()

2011-03-25 Thread Yonik Seeley
On Fri, Mar 25, 2011 at 2:06 PM, Michael McCandless wrote: > On Fri, Mar 25, 2011 at 12:02 PM, Yonik Seeley > wrote: > >> Currently, supplying a filter to IndexSearcher.search() assumes that >> it's cheaper to run than the main query. > > Wait, where do we assume that? After a match, we always s

Re: add an "afterFilter" to IndexSearcher.search()

2011-03-25 Thread Michael McCandless
On Fri, Mar 25, 2011 at 12:02 PM, Yonik Seeley wrote: > Currently, supplying a filter to IndexSearcher.search() assumes that > it's cheaper to run than the main query. Wait, where do we assume that? Today, the filter & scorer "leap frog" each other. Ie we alternate between them, calling .advan

add an "afterFilter" to IndexSearcher.search()

2011-03-25 Thread Yonik Seeley
Currently, supplying a filter to IndexSearcher.search() assumes that it's cheaper to run than the main query. We should add the following method to IndexSearcher: public void search(Query query, Filter beforeFilter, Filter afterFilter, Collector results) beforeFilter would be skipped first when