[
https://issues.apache.org/jira/browse/LUCENE-6539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14579568#comment-14579568
]
Robert Muir commented on LUCENE-6539:
-------------------------------------
I don't think this query should be a standalone one. It forces users to decide
which one to use, and they will fuck this up.
every time.
Its ok in current form to go to sandbox, but i think this needs to be
integrated into the inverted approach so that based on index stats, lucene can
just do the right thing.
> 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
