On Nov 7, 2007 4:10 PM, Mike Klaas <[EMAIL PROTECTED]> wrote: > Not sure if this went through--I sent using the wrong email addr. > > I've also posted a patch: > [ https://issues.apache.org/jira/browse/SOLR-407? > page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] > > ---------------------------------------------------------------------- > > I'm thinking of implementing something like "fq.nocache": a query > restriction that would not be cached in filterCache. > > This is actually somewhat tricky to implement in the Guts of > SolrIndexSearcher without adding a lot to the interface. Then I > realized that without caching, there really is no point in computing > separate BitSets and intersecting them: it would be better to insert > them directly into the BooleanQuery (or a wrapping BooleanQuery). > This would also provide nicer skipTo behaviour (perhaps most docs > needn't be scored before applying the filter).
Right. This can speed things up if the filter matches few documents. > 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... Rather than fq.nocache, how about decorating the existing fq via localParams: fq=<!cache=false> We already look for localParams anyway for query type info... so you could also have something like: fq=<!prefix f=myfield cache=false>foo -Yonik
