Use of cache=false and Cost Parameters

from the day solr 3.4 was released its users got a nice feature which decides if the results of a filter query or query should be placed in cache. in addition to that we got the possibility to set filter query cost. let’s see how to use those features.

parameter cache=false

setting the cache parameter to false we tell solr not to cache current query results. this parameter can also be used as a filter query ( fq ) attribute, which tell solr not to cache filter query results. what do we get from such behavior ? let’s imagine the following filter as a part of the query:

fq={!frange l=10 u=100}log(sum(sqrt(popularity),100))

if we know that the queries with filter like the above one are rare, we can decide not to cache them and not change cache state for irrelevant data. to do that we add the cache=false attribute in the following way:

fq={!frange l=10 u=100 cache=false}log(sum(sqrt(popularity),100))

as i told, adding this additional attribute will result in the filter results not being cached.

parameter cost

the additional feature of solr 3.4 is the possibility to set filter cost in case of those filters that we don’t want to cache. filter queries with specified cost are executed as last ones after all the cached filters. the cost attribute is specified as the integer value. let’s look at the following example filters:

fq=cat:video&fq={!cache=false cost=50}productgroup:12&fq={!frange l=10 u=100 cache=false cost=150}log(sum(sqrt(popularity),100))

the first filter to execute will be the fq=cat:video one because it is cached. the next one to evaluate will be the one with lesser cost value, so the fq={!cache=false cost=50} . the last filter to evaluate will be the most expensive filter. in addition the last filter will operate only on documents that match the main query and all previous filters (because its cost attribute is higher than 100).

you should remember that cost attribute work only when the filter query is not cached.

to sum up

with cache and cost attributes we can control what we place in solr cache, which is very good in most situation, when we know what queries are sent to solr instances. whats more, using those attributes we can improve query performance, for those queries that have filters with cost higher than 100. i think it’s worth to take a while, look at your queries and think about if you need to cache all of those