On 7/10/2015 5:55 AM, Thomas Seidl wrote: > I am working a lot with Drupal and Apache Solr. There, we implemented a > performance improvement that would, for filter-only queries (i.e., no > "q" parameter, just "fq"s) instead move the filters to the "q.alt" > parameter (idea based on this blog post [1]). > > [1] > https://web.archive.org/web/20120817044656/http://www.derivante.com/2009/04/27/100x-increase-in-solr-performance-and-throughput > > Before, we had "q.alt=*:*" to return all results and then filter via > "fq". So, e.g., this query: > q.alt=*:*&fq=field1:foo&fq=field2:bar > becomes this: > q.alt=(field1:foo) AND (field2:bar) > > However, now I've read some complaints that the former is actually > faster, and some other people also pointed out (in separate discussions) > that "fq" is much faster than "q". > > So, can anyone shed some lights on this, what the internal mechanics are > that make the one or the other faster? Are there other suggestions for > how to make a "filters-only" search as fast as possible? > > Also, can it be that it recently changed that the "q.alt" parameter now > influences relevance (in Solr 5.x)? I could have sworn that wasn't the > case previously.
The first time you execute a particular filter after Solr startup, core reload, and MAYBE after an index commit, the performance is likely to be better for q.alt over fq, because fq works over the entire index and some parts of q.alt only need to deal with the top N docs. If you use the same filters repeatedly, fq will perform better. This is due to the filterCache. If the filters are different every time (which would be the case on EVERY query if you use NOW instead of NOW/HOUR or NOW/DAY in date filters), then the filterCache may not be able to provide any benefit. As for relevance, q and q.alt have *always* affected relevance. If you don't want relevance to be affected, you will need to use fq. Thanks, Shawn
