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: [email protected]
For additional commands, e-mail: [email protected]
