[ 
https://issues.apache.org/jira/browse/LUCENE-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12651109#action_12651109
 ] 

Michael McCandless commented on LUCENE-1470:
--------------------------------------------


It seems like there are two things you might want to make "pluggable":

  - Which hierarchical ranges to create & logic that creates them for
    a given value.  For certain types (dates) I think there's one
    obvious set of ranges (year, quarter, month, day, etc.).  For
    something like "price" it's probably more app dependent, eg if you
    present certain filters/facets to the user.

  - What label is attached to each range, and the correspond decoder
    to map that label back into its upper/lower values.

So we could provide good defaults for eg Date.  The labels would
ideally be things like 2007, 2008 and "Jan 2008", "Feb 2008", etc.  I
think?  Hmm -- except for the need to sort them "properly".

We really should change Lucene's terms so that they are opaque objects
(as KS/Lucy is doing).  This way you could store a Term like "Feb
2008" in the index, along with details like "this is a generated
ranged datetime term" and the numeric date details ie 02/2008, and
you'd just have to export a compareTo to Lucene.


> 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
>         Attachments: 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]

Reply via email to