[jira] [Commented] (LUCENE-6720) new FunctionRangeQuery, plus ValueSourceScorer improvements

["Adrien Grand (JIRA)" <ji...@apache.org>]

    [ 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org