[jira] [Created] (SOLR-11641) {!frange} / FunctionRangeQuery should default to 100==getCost() so non-cached fq's default to post-filtering

["Hoss Man (JIRA)" <ji...@apache.org>]

Hoss Man created SOLR-11641:
-------------------------------

             Summary: {!frange} / FunctionRangeQuery should default to 100==getCost() so non-cached fq's default to post-filtering
                 Key: SOLR-11641
                 URL: https://issues.apache.org/jira/browse/SOLR-11641
             Project: Solr
          Issue Type: Improvement
      Security Level: Public (Default Security Level. Issues are Public)
          Components: query parsers
            Reporter: Hoss Man
            Assignee: Hoss Man


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.





--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org