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

    XMLWordPrintableJSON

Details

    • Improvement
    • Status: Closed
    • Major
    • Resolution: Fixed
    • None
    • 7.2, 8.0
    • query parsers
    • None

    Description

      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.

      Attachments

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

        Issue Links

          Activity

            People

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

              Dates

                Created:
                Updated:
                Resolved: