[
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
