lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (JIRA)" <>
Subject [jira] [Commented] (LUCENE-6697) Use 1D KD tree for alternative to postings based numeric range filters
Date Tue, 18 Aug 2015 19:26:46 GMT


Michael McCandless commented on LUCENE-6697:

bq. My Jenkins found a failing seed on branch_5x w/Java8 for TestRangeTree.testAllEqual()

This was a fun one to track down :) is the root cause...

> Use 1D KD tree for alternative to postings based numeric range filters
> ----------------------------------------------------------------------
>                 Key: LUCENE-6697
>                 URL:
>             Project: Lucene - Core
>          Issue Type: New Feature
>            Reporter: Michael McCandless
>            Assignee: Michael McCandless
>             Fix For: 5.3, Trunk
>         Attachments: LUCENE-6697.patch, LUCENE-6697.patch, LUCENE-6697.patch
> Today Lucene uses postings to index a numeric value at multiple
> precision levels for fast range searching.  It's somewhat costly: each
> numeric value is indexed with multiple terms (4 terms by default)
> ... I think a dedicated 1D BKD tree should be more compact and perform
> better.
> It should also easily generalize beyond 64 bits to arbitrary byte[],
> e.g. for LUCENE-5596, but I haven't explored that here.
> A 1D BKD tree just sorts all values, and then indexes adjacent leaf
> blocks of size 512-1024 (by default) values per block, and their
> docIDs, into a fully balanced binary tree.  Building the range filter
> is then just a recursive walk through this tree.
> It's the same structure we use for 2D lat/lon BKD tree, just with 1D
> instead.  I implemented it as a DocValuesFormat that also writes the
> numeric tree on the side.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message