Uploaded image for project: 'Solr'
  1. Solr
  2. SOLR-11641

{!frange} / FunctionRangeQuery should default to 100==getCost() so non-cached fq's default to post-filtering



    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 7.2, 8.0
    • Component/s: query parsers
    • Labels:


      While reviewing the code paths that can result in the execution of an 'fq', I realized that executing an '{!frange cache=false ... }' query (with default 'cost=0' localparam) that matches "very few" documents (compared to the other q/fq clauses) can result in a pathelogical "bad" case situation where the function is computed unneccessarily for lots of documents in order for the Scorer to satisfy the advance(int) API of returning the "next" matching document – making that situation benefit from using the post-filter code path just as much as if the {{'{!frange}'"" matches "very many" documents (compared to the other q/fq clauses)

      In other words: because FunctionRangeQuery has no ability to effectively "skip ahead" to the next match, there is no advantage (that I can see) in executing a FunctionRangeQuery as "regular" Filter in a Conjunction with the other query clauses.

      I think we should change the default behavior of '{!frange}' so that the effective default cost==100 so that when a user specifies cache==false they run as post filters.


        1. SOLR-11641.patch
          11 kB
          Chris M. Hostetter
        2. SOLR-11641.patch
          8 kB
          Chris M. Hostetter
        3. SOLR-11641.patch
          0.6 kB
          Chris M. Hostetter

          Issue Links



              • Assignee:
                hossman Chris M. Hostetter
                hossman Chris M. Hostetter
              • Votes:
                0 Vote for this issue
                3 Start watching this issue


                • Created: