lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler (JIRA)" <>
Subject [jira] Commented: (LUCENE-1470) Add TrieRangeQuery to contrib
Date Sat, 07 Feb 2009 18:20:59 GMT


Uwe Schindler commented on LUCENE-1470:

Thanks for the code fragments, I can take this as basis and will implement the TrieRangeFilter
counterpart. I have some more ideas (e.g. for the beginners API there is missing the possibility
to *store* the full-precision value). And norms should be disabled per default (in beginners
API). 32bit support is also simple, as you noted.

The problem is now, how to make TrieRangeFilter so generic, to support all posible encodings
and field names possible (with your code, it would also be possible to put each precision
in a separate field). I work on that, I want to have clean API on the TrieRangeFilter!

I would name both addIndexedFields() and addField with the same name (just overload), but
different options. I prepare that!

I agree, date support is not needed. And if I would again add Date support, Calendars should
also be possible etc. No need for that - Date should be deprecated by Sun!

One question: The encoding is now different from NumberUtils again - NumberUtils tries to
get the most out of each char vs. this tries to not affect UTF-8 encoding and use ASCII only?
Would Solr use this encoding in future (7bit chars) for numeric values or should be both separate?
These TrieUtils now also make it possible to not use trie coding, but encode doubles/longs
for other use (and use the currently missing LongParser/SortField generators).

> Add TrieRangeQuery to contrib
> -----------------------------
>                 Key: LUCENE-1470
>                 URL:
>             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,
> According to the thread in java-dev (
and, 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:
For additional commands, e-mail:

View raw message