lucene-solr-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Solr Wiki] Update of "CommonQueryParameters" by YonikSeeley
Date Sat, 02 Jul 2011 21:14:58 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Solr Wiki" for change notification.

The "CommonQueryParameters" page has been changed by YonikSeeley:
http://wiki.apache.org/solr/CommonQueryParameters?action=diff&rev1=38&rev2=39

Comment:
document cache=false, cost, post filtering

  The following list of parameters are supported by SearchHandler.  Although they are not
mandatory, it is strongly encouraged that all Future !SolrRequestHandlers support them as
well.  [[http://lucene.apache.org/solr/api/org/apache/solr/util/SolrPluginUtils.html|Some
Utilities]] exist to make implementing them easy.
  
  <<TableOfContents>>
+ 
+ <<Anchor(q)>>
+ == q ==
+ The '''q''' parameter is normally the main query for the request.
+ See [[SolrQuerySyntax|Solr query syntax]] for more information on different types of queries
and syntaxes.
  
  <<Anchor(sort)>>
  == sort ==
@@ -63, +68 @@

  }}}
     1. The document sets from each filter query are cached independently.  Thus, concerning
the previous examples: use a single fq containing two mandatory clauses if those clauses appear
together often, and use two separate fq params if they are relatively independent.
     1. As with all parameters: when expressed in a URL, special characters need to be [[SolrQuerySyntax#urlescaping|
properly URL escaped]].
+ 
+ === Caching of filters ===
+ Each filter query is normally generated and cached independently in the '''filterCache''',
leading to improved request throughput for filters that are likely to be reused.
+ Starting with [[Solr3.4]], the [[LocalParams|local param]] '''cache=false''' can be added
at the top-level of any filter query, and cause that filter to not be generated up front and
cached, but instead executed in parallel with the query and all other filters.  This can be
beneficial for filters that will not be reused in other requests (thus avoiding polluting
the filterCache) and for filters that are very expensive to evaluate for every document in
the index.
+ 
+  . Example: {{{q=*:*&fq={!cache=false}inStock:true}}}
+  . Example: {{{q=*:*&fq={!frange l=1 u=4 cache=false}sqrt(popularity)}}}
+ 
+ There is also an optional "cost" local param that controls the order in which non-cached
filter queries are evaluated, so knowledgable users can order less expensive non-cached filters
before expensive non-cached filters.
+ 
+  . Example: {{{q=*:*&fq={!cache=false cost=5}inStock:true&fq={!frange l=1 u=4 cache=false
cost=50}sqrt(popularity)}}}
+ 
+ As an additional feature for very high cost filters, if cache=false and cost>=100 and
the query implements the [[https://builds.apache.org/job/Solr-3.x/javadoc/org/apache/solr/search/PostFilter.html|PostFilter]]
interface, a Collector will be requested from that query and used to filter documents only
after they have matched the main query and all other filter queries.  There can be multiple
post filters, and they are also ordered by cost.  The '''frange''' parser currently supports
post filtering, useful when the referenced function query is very expensive.
+ 
+  . Example: {{{q=*:*&fq={!frange l=1 u=4 cache=false cost=150}sqrt(popularity)}}}
+ 
  
  <<Anchor(fl)>>
  == fl ==

Mime
View raw message