[
https://issues.apache.org/jira/browse/LUCENE-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12653270#action_12653270
]
Uwe Schindler commented on LUCENE-1470:
---------------------------------------
Thanks, then I would also change TestTrieRangeQuery to also use LuceneTestCase,
just for completeness.
bq. Sigh, you are correct. How would you fix FieldCache?
I would fix FieldCache by giving in SortField the possibility to supply a
parser instance. So you create a SortField using a new constructor
SortField(String field, int type, Object parser, boolean reverse). The parser
is "object" bcause all parsers have no super-interface. The ideal solution
would be to have:
SortField(String field, int type, FieldCache.Parser parser, boolean reverse)
and FieldCache.Parser is a super-interface (just empty, more like a
marker-interface) of all other parsers (like LongParser...)
bq. I guess the workaround is to also index the original value (unencoded by
TrieUtils) as an additional field, for sorting.
The problem with the extra field would be, that it works good for longs or
doubles (with some extra work), but Dates still keep as String, or you use
Date.getTime() as long. But this is not very elegant and needs more fields and
terms. I prefer a clean solution.
> Add TrieRangeQuery to contrib
> -----------------------------
>
> Key: LUCENE-1470
> URL: https://issues.apache.org/jira/browse/LUCENE-1470
> Project: Lucene - Java
> Issue Type: New Feature
> Components: contrib/*
> Affects Versions: 2.4
> Reporter: Uwe Schindler
> Assignee: Michael McCandless
> Fix For: 2.9
>
> Attachments: fixbuild-LUCENE-1470.patch, fixbuild-LUCENE-1470.patch,
> LUCENE-1470.patch, LUCENE-1470.patch, LUCENE-1470.patch, LUCENE-1470.patch,
> LUCENE-1470.patch, LUCENE-1470.patch, LUCENE-1470.patch
>
>
> According to the thread in java-dev
> (http://www.gossamer-threads.com/lists/lucene/java-dev/67807 and
> http://www.gossamer-threads.com/lists/lucene/java-dev/67839), I want to
> include my fast numerical range query implementation into lucene
> contrib-queries.
> I implemented (based on RangeFilter) another approach for faster
> RangeQueries, based on longs stored in index in a special format.
> The idea behind this is to store the longs in different precision in index
> and partition the query range in such a way, that the outer boundaries are
> search using terms from the highest precision, but the center of the search
> Range with lower precision. The implementation stores the longs in 8
> different precisions (using a class called TrieUtils). It also has support
> for Doubles, using the IEEE 754 floating-point "double format" bit layout
> with some bit mappings to make them binary sortable. The approach is used in
> rather big indexes, query times are even on low performance desktop
> computers <<100 ms (!) for very big ranges on indexes with 500000 docs.
> I called this RangeQuery variant and format "TrieRangeRange" query because
> the idea looks like the well-known Trie structures (but it is not identical
> to real tries, but algorithms are related to it).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
