I _think_ it will run all 3 and then do index hopping. But if you know one fq is super expensive, you could assign it a cost Value over 100 will try to use PostFilter then and apply the query on top of results from other queries.
https://lucene.apache.org/solr/guide/8_4/common-query-parameters.html#cache-parameter Hope it helps, Alex. On Thu., Jul. 9, 2020, 2:05 p.m. Chris Dempsey, <cdal...@gmail.com> wrote: > Hi all! In a collection where we have ~54 million documents we've noticed > running a query with the following: > > "fq":["{!cache=false}_class:taggedTickets", > "{!cache=false}taggedTickets_ticketId:1000000241", > "{!cache=false}companyId:22476"] > > when I debugQuery I see: > > "parsed_filter_queries":[ > "{!cache=false}_class:taggedTickets", > "{!cache=false}IndexOrDocValuesQuery(taggedTickets_ticketId:[1000000241 > TO 1000000241])", > "{!cache=false}IndexOrDocValuesQuery(companyId:[22476 TO 22476])" > ] > > runs in roughly ~450ms but if we remove `{!cache=false}companyId:22476` it > drops down to ~5ms (it's important to note that `taggedTickets_ticketId` is > globally unique). > > If we change the fqs to: > > "fq":["{!cache=false}_class:taggedTickets", > "{!cache=false}+companyId:22476 +taggedTickets_ticketId:1000000241"] > > when I debugQuery I see: > > "parsed_filter_queries":[ > "{!cache=false}_class:taggedTickets", > "{!cache=false}+IndexOrDocValuesQuery(companyId:[22476 TO 22476]) > +IndexOrDocValuesQuery(taggedTickets_ticketId:[1000000241 TO 1000000241])" > ] > > we get the correct result back in ~5ms. > > My current thought is that in the slow scenario Solr is still running > `{!cache=false}IndexOrDocValuesQuery(companyId:[22476 > TO 22476])` even though it "has the answer" from the first two fq. > > Am I off-base or misunderstanding how `fq` are processed? >
