I have a query like: q=<some complicated stuff>&fq=enabled:true
For purposes of this conversation, "fq=enabled:true" is set for every query, I never open a new searcher, and this is the only fq I ever use, so the filter cache size is 1, and the hit ratio is 1. The fq=enabled:true clause matches about 15% of my documents. I have some 20M documents per shard, in a 5.3 solrcloud cluster. Under these circumstances, this alternate version of the query averages about 1/3 faster, consumes less CPU, and generates less garbage: q=<some complicated stuff> +enabled:true So it appears I have a case where using the cached fq result is more expensive than just putting the same restriction in the query. Does someone have a clear mental model of how “q” and “fq” interact? Naively, I’d expect that either the “q” operates within the set matched by the fq (in which case it’s doing "complicated stuff" on only a subset and should be faster) or that Solr takes the intersection of the q & fq sets (in which case putting the restriction in the “q” means that set needs to be generated instead of retrieved from cache, and should be slower). This has me wondering, if you want fq cache speed boosts, but also want ranking involved, can you do that? Would something like q=<some other stuff> AND <particular query>&fq=<particular query> help, or just be more work? Thanks.
