[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
• Fix Version/s: 7.2, 8.0
• Component/s: query parsers
• Assignee: Chris M. Hostetter
• Reporter: Chris M. Hostetter
• Created: 13/Nov/17 18:40
• Updated: 08/Jun/19 15:13
• Resolved: 14/Nov/17 18:58

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.

Issue Links

• is related to: SOLR-11679 TraveValueSource & trace() parser