[ https://issues.apache.org/jira/browse/LUCENE-6539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14579566#comment-14579566 ]
Adrien Grand commented on LUCENE-6539: -------------------------------------- This new query looks good to me. However instead of keeping adding such queries to core, I think we should consider moving all our doc values queries to misc since they have complicated trade-offs and are only useful in expert use-cases? {code} + private static Set<Long> toSet(Long[] array) { + Set<Long> numbers = new HashSet<>(); + for(Long number : array) { + numbers.add(number); + } + return numbers; + } {code} FYI you don't need this helper and could do just: {{new HashSet<Long>(Arrays.asList(array))}}. bq. in certain cases (many terms/numbers and fewish matching hits) it should be faster than using TermsQuery This comment got me confused: I think in general these queries are more efficient when they match _many_ documents, ie. even when an equivalent TermsQuery would not be used as a lead iterator in a conjunction? I think the only case when such a query matching few documents would be useful would be in a prohibited clause since these prohibited clauses can never be used to lead iteration anyway and are only used in a random-access fashion? > Add DocValuesNumbersQuery, like DocValuesTermsQuery but works only with long > values > ----------------------------------------------------------------------------------- > > Key: LUCENE-6539 > URL: https://issues.apache.org/jira/browse/LUCENE-6539 > Project: Lucene - Core > Issue Type: New Feature > Reporter: Michael McCandless > Assignee: Michael McCandless > Fix For: Trunk, 5.3 > > Attachments: LUCENE-6539.patch > > > This query accepts any document where any of the provided set of longs > was indexed into the specified field as a numeric DV field > (NumericDocValuesField or SortedNumericDocValuesField). You can use > it instead of DocValuesTermsQuery when you have field values that can > be represented as longs. > Like DocValuesTermsQuery, this is slowish in general, since it doesn't > use an inverted data structure, but in certain cases (many > terms/numbers and fewish matching hits) it should be faster than using > TermsQuery because it's done as a "post filter" when other (faster) > query clauses are MUST'd with it. > In such cases it should also be faster than DocValuesTermsQuery since > it skips having to resolve terms -> ords. -- This message was sent by Atlassian JIRA (v6.3.4#6332) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org