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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

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

JIRA jira@apache.org

    [ https://issues.apache.org/jira/browse/SOLR-11641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16251478#comment-16251478 ]

David Smiley commented on SOLR-11641:
-------------------------------------

+1 nice analysis Hoss

> {!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
>         Attachments: SOLR-11641.patch, SOLR-11641.patch
>
>
> 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: [hidden email]
For additional commands, e-mail: [hidden email]