: > Is there any reason to think that this wouldn't be the most efficient : > solution? Obviously the clauses would be inserted with 0 boost. : : I was going to suggest that the client could always just add the extra : clause themselves, but then I thought about dismax...
there' a broader issue as well ... people might want the "q" to come from one place (ie: user text box input) while the "fq.nocache" comes from somewhere else (ie: default configs, radio button option, etc...). Let's back up a second... the theory is that while it's frequently handy to cache fq's independent of the main query (because they are probably used over and over) in some cases it may be advantageous to use an FQ directly in the body of hte main query to get better skipTo behavior. -- the fundemental issue is orthogonal to wether or not a DocSet for the FQ is cached, the question is how should that FQ be used when computing the final DocList. So what if instead of letting the client say "this argument is an fq which should be used to generate a BitSet and cached as a filter, this argument is an fq.nocache which should be added to the main query" we instead make SolrIndexSearcher smart enough to say "i've been asked to filter the main query using some DocSets, the intersection of those DocSets is small enough, that instead of filtering the query on it, i'm going to add a query that only matches docs in it to the main query to improve skipTo behavior." ... so now clients don't have to know, they just pass in a bunch of fq params. we still cache a DocSet for each one, but when it comes time to do the search, we get the skipTo benefit anytime the intersection of all fqs is really small (wether the individual fqs are small enough individually or not) that should just be a simple change to getDocListNC right? -Hoss
