You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@lucene.apache.org by "David Smiley (Jira)" <ji...@apache.org> on 2020/08/13 04:26:00 UTC
[jira] [Commented] (LUCENE-9373) Allow FunctionMatchQuery to
customize matchCost of TwoPhaseIterator
[ https://issues.apache.org/jira/browse/LUCENE-9373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176757#comment-17176757 ]
David Smiley commented on LUCENE-9373:
--------------------------------------
Thanks for the patch [~Maxim Glazkov] ! I applied it in my IDE and made some trivial changes (e.g. I prefer "final" to be _after_ "static"), and some javadoc edits to link directly to TPI matchCost. I learned something new from your patch – the javadoc \{\@value } reference.
I noticed that there's an equals & hashCode that do not take this new matchCost into consideration. I suppose that's for the best because it's only an implementation hint; it should not change any semantics. I added a comment about that.
I wondered -- what if one day DoubleValues finally has its own matchCost -- what then. It would not obsolete what we have here because the matchCost here is both explicit (maybe the user-developer knows better what the matchCost should be), and furthermore the cost is more than the DoubleValues -- it's also that of the predicate.
[~romseygeek] Unrelated to this issue/patch but pertinent to MatchCostQuery: I see MatchCostQuery uses a DoublePredicate and it includes this in the equals/hashcode as it should. Shouldn't we advice the caller in javadocs that the predicate _must_ implement equals/hashcode _if_ this query might be cached?. Failing to do so (e.g. a lambda impl) will mean the query will never get a cache hit. Maybe the very use of DoublePredicate is just asking for trouble and we should define a class similarly with equals/hashcode as abstract?
> Allow FunctionMatchQuery to customize matchCost of TwoPhaseIterator
> -------------------------------------------------------------------
>
> Key: LUCENE-9373
> URL: https://issues.apache.org/jira/browse/LUCENE-9373
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/queries
> Reporter: David Smiley
> Priority: Major
> Labels: newdev
> Attachments: LUCENE-9373.patch
>
>
> FunctionMatchQuery internally has a TwoPhaseIterator using a constant matchCost. If it were customizable by the query, the user could control this ordering. I propose an optional matchCost via an overloaded constructor. Ideally the DoubleValues abstraction would have a matchCost but it doesn't, and even if it did, the user might just want real control over this at a query construction/parse level.
> See similar LUCENE-9114
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org