[
https://issues.apache.org/jira/browse/LUCENE-6720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14658412#comment-14658412
]
Adrien Grand commented on LUCENE-6720:
--------------------------------------
{code}
+ if (lowerVal != null ? !lowerVal.equals(that.lowerVal) : that.lowerVal !=
null) return false;
+ return !(upperVal != null ? !upperVal.equals(that.upperVal) :
that.upperVal != null);
{code}
This is a bit hard to read for me (many negations), maybe we could do something
like
{code}
return Objects.equals(lowerVal, that.lowerVal) && Objects.equals(upperVal,
that.upperVal)?
{code}
explain calls scorer.advance(doc), which could be very slow if the index is
large and has few docs in the range, could we just check if the given doc is in
range?
> Future: don’t match if FunctionValues.exists() returns false? How to prevent
> extra value fetching? I don’t know why it should care.
Indeed I don't think it should match docs that don't have a value. This
behaviour you are seeing with IntFieldSource is consistent with what we are
doing with doc values: doc values guarantee that if a doc misses a value, then
the NumericDocValues will return 0 as a value. This way most of the time you
can know both that a document has a value and its value with a single random
access. We only need to check the bit set for missing values (which is
disk-based) when a doc value is exactly 0.
I can't help with the MutableValue/ValueFiller API, it is odd to me to.
> new FunctionRangeQuery, plus ValueSourceScorer improvements
> -----------------------------------------------------------
>
> Key: LUCENE-6720
> URL: https://issues.apache.org/jira/browse/LUCENE-6720
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: David Smiley
> Assignee: David Smiley
> Attachments: LUCENE-6720__FunctionRangeQuery.patch
>
>
> This issue provides a new FunctionRangeQuery, which is basically a wrapper
> around ValueSourceScorer (retrieved from FunctionValues.getRangeScorer). It
> replaces ValueSourceFilter in the spatial module. Solr has a class by the
> same name which is similar but isn't suitable to being ported.
> Also, it includes refactorings to the ValueSourceScorer, to include
> performance enhancements by making it work with the TwoPhaseIterator API.
> note: I posted this to LUCENE-4251 initially but then felt it's really its
> own issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
