lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn Heisey <>
Subject Re: Performance of q.alt vs. fq
Date Fri, 10 Jul 2015 13:04:48 GMT
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]
> 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.


View raw message