[
https://issues.apache.org/jira/browse/LUCENE-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12671634#action_12671634
]
Uwe Schindler commented on LUCENE-1470:
---------------------------------------
I am still "reading" your code, but the main parts look identical (also the
break condition, if no inner range available -> this condition is very
important and must be min>=max). There are only differences between both are
the generation of the inner range bounds. I just rewrote my old code, did you
do it completely from scratch?
I would change RangeBuilder to be only a interface/abstract class with no
Object return code that has a addRange method. The range will always be or'ed
(anding makes no sense). The same idea came me, when I tried to unify the 32bit
and 64 bit variant in my TrieRangeFilter code.
For performance reasons, it is better to use the same TermEnum and TermDocs and
only one OpenBitSet when executing the range. But this can be easily handled
using the interface (RangeBuilder initializes the Openbitset, TermDocs and
TermEnums, like in my code. When the range was built, the OpenBitset is
retrieved).
> 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: Uwe Schindler
> Fix For: 2.9
>
> Attachments: fixbuild-LUCENE-1470.patch, fixbuild-LUCENE-1470.patch,
> LUCENE-1470-readme.patch, LUCENE-1470.patch, LUCENE-1470.patch,
> LUCENE-1470.patch, LUCENE-1470.patch, LUCENE-1470.patch, LUCENE-1470.patch,
> LUCENE-1470.patch, TrieRangeFilter.java, TrieUtils.java, TrieUtils.java,
> TrieUtils.java, TrieUtils.java, TrieUtils.java
>
>
> 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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
