Thank you Jonathan. "fq=foo:bar&fq=foo:baz" seems to be the better alternative for "fq=foo:bar AND foo:baz" if "foo:bar" and "foo:baz" were often used in different combinations (not always together).
However, in most of the usecases I can think of, an "fq=foo:bar OR foo:baz"-behaviour is expected and it would be nice if this fq would benefit from a cached "fq=foo:bar". I can imagine why this is not the case, if only one of two fq-clauses were cached. However, when "foo:bar" and "foo:baz" were cached seperately, why not benefiting from them when a "fq=foo:bar OR foo:baz" or "fq=foo:bar AND foo:baz" is requested? Who is responsible for putting fq's in the filterCache? I think one has to modify the logic of that class do benefit from already cached but recombined filterCaches. This would have a little bit less performance than caching the entire "foo:bar AND foo:baz" BitVector, since you need to reproduce one for that special use-case, but I think the usage of the cache is far more efficient, if "foo:bar" and "foo:baz" occur very frequently but "foo:bar AND foo:baz" do not. What do you think? Regards Jonathan Rochkind wrote: > > Each 'fq' clause is it's own cache key. > > 1. fq=foo:bar OR foo:baz > => one entry in filter cache > > 2. fq=foo:bar&fq=foo:baz > => two entries in filter cache, will not use cached entry from #1 > > 3. fq=foo:bar > => One entry, will use cached entry from #2 > > 4. fq=foo:bar > => One entry, will use cached entry from #2. > > So if you do queries in succession using each of those four fq's in > order, you will wind up with 3 entries in the cache. > > Note that "fq=foo:bar OR foo:baz" is not semantically identical to > "fq=foo&fq=bar". Rather that latter is semantically identical to > "fq=foo:bar AND foo:baz". But "fq=foo&fq=bar" will be two cache > entries, and "fq=foo:bar AND foo:baz" will be one cache entry, and the > two won't share any cache entries. > > > On 1/5/2011 3:17 PM, Em wrote: >> Hi, >> >> while reading through some information on the list and in the wiki, i >> found >> out that something is missing: >> >> When I specify a filter queries like this >> >> fq=foo:bar OR foo:baz >> or >> fq=foo:bar&fq=foo:baz >> or >> fq=foo:bar >> or >> fq=foo:baz >> >> How many filter query entries will be cached? >> Two, since there are two filters (foo:bar, foo:baz) or 3, since there are >> three different combinations (foo:bar OR foo:baz, foo:bar, foo:baz)? >> >> Thank you! > > Jonathan Rochkind wrote: > > Each 'fq' clause is it's own cache key. > > 1. fq=foo:bar OR foo:baz > => one entry in filter cache > > 2. fq=foo:bar&fq=foo:baz > => two entries in filter cache, will not use cached entry from #1 > > 3. fq=foo:bar > => One entry, will use cached entry from #2 > > 4. fq=foo:bar > => One entry, will use cached entry from #2. > > So if you do queries in succession using each of those four fq's in > order, you will wind up with 3 entries in the cache. > > Note that "fq=foo:bar OR foo:baz" is not semantically identical to > "fq=foo&fq=bar". Rather that latter is semantically identical to > "fq=foo:bar AND foo:baz". But "fq=foo&fq=bar" will be two cache > entries, and "fq=foo:bar AND foo:baz" will be one cache entry, and the > two won't share any cache entries. > > > On 1/5/2011 3:17 PM, Em wrote: >> Hi, >> >> while reading through some information on the list and in the wiki, i >> found >> out that something is missing: >> >> When I specify a filter queries like this >> >> fq=foo:bar OR foo:baz >> or >> fq=foo:bar&fq=foo:baz >> or >> fq=foo:bar >> or >> fq=foo:baz >> >> How many filter query entries will be cached? >> Two, since there are two filters (foo:bar, foo:baz) or 3, since there are >> three different combinations (foo:bar OR foo:baz, foo:bar, foo:baz)? >> >> Thank you! > > -- View this message in context: http://lucene.472066.n3.nabble.com/FQ-Filter-Query-Caching-Differences-with-OR-and-AND-tp2201004p2204235.html Sent from the Solr - User mailing list archive at Nabble.com.
