Ah thanks. I see it was added in 5.1 - is there any other way prior to that (like 4.7)?
if not, I guess the only option is to not use fq if we don't intend to cache it, and on 5.1 use the ^= syntax. Shai On Wed, Jun 24, 2015 at 9:21 PM, Jack Krupansky <jack.krupan...@gmail.com> wrote: > Yonik added syntax to request a constant score query in Solr with the ^= > operator. > > For example: +color:blue^=1 text:shoes > > See: > https://issues.apache.org/jira/browse/SOLR-7218 > > -- Jack Krupansky > > On Wed, Jun 24, 2015 at 1:41 PM, Shai Erera <ser...@gmail.com> wrote: > > > Thanks Shawn, > > > > What's Solr equivalence to ConstantScoreQuery? I.e., what if you want to > > run a query that does not score, but only filter. The rationale behind > > using a non-cached 'fq' was just that. > > > > Shai > > > > On Wed, Jun 24, 2015 at 4:29 PM, Shawn Heisey <apa...@elyograg.org> > wrote: > > > > > On 6/24/2015 5:28 AM, Esther Goldbraich wrote: > > > > We are comparing the performance of fq versus q for queries that are > > > > actually filters and should not be cached. > > > > In part of queries we see strange behavior where q performs 5-10x > > better > > > > than fq. The question is why? > > > > > > > > An example1: > > > > q=maildate:{DATE1 to DATE2} COMPARED TO > > fq={!cache=false}maildate:{DATE1 > > > > to DATE2} > > > > sort=maildate_sort* desc > > > > > > <snip> > > > > > > > <field name="maildate" stored="true" indexed="true" type="tdate"/> > > > > <field name="maildate_sort" stored="false" indexed="false" > type="tdate" > > > > docValues="true"/> > > > > > > For simplicity, I would probably just use one field for that, rather > > > than a separate sort field. The disk space required would probably be > > > the same either way, but your interaction with the index will not be as > > > complex. There's nothing wrong with doing it the way you have, though. > > > > > > I'm not at all an expert, but I've been a member of this community for > a > > > long time. Here's my guess about why your query is faster in the q > > > parameter than a non-cached filter: > > > > > > The result of a standard query is the stored fields from the top N > > > documents, where N is the value in the rows parameter. The default for > > > N is typically set to 10, and for most people will normally be 200 or > > less. > > > > > > The result of a filter is very different -- it is a bitset of all the > > > documents in your entire index, with binary 0 for documents that don't > > > match the filter and binary 1 for documents that do match. > > > > > > If your index has 100 million documents, every single one of those 100 > > > million documents must be checked against the filter query to produce a > > > filter bitset, but when it's in the q parameter, shortcuts can be taken > > > which will get the top N results quickly. > > > > > > The filterCache levels the playing field when filters are re-used. If > a > > > requested filter is already in the cache, it can be retrieved and > > > applied to a result VERY quickly. > > > > > > You have turned off the caching for your filter. I'm not sure why you > > > did this, but you know your use case a lot better than I do. If it > were > > > me, I would use filter queries and do everything possible to re-use the > > > same filters, and I would cache them. > > > > > > Thanks, > > > Shawn > > > > > > > > >
