See also my recent blog post describing this new feature:
https://www.elastic.co/blog/lucene-points-6.0

Net/net, in the 1D case, points looks like a win across the board vs.
the legacy (postings) implementation.

Mike McCandless

http://blog.mikemccandless.com


On Thu, Mar 24, 2016 at 12:33 PM, Robert Muir <[email protected]> wrote:
> On Thu, Mar 24, 2016 at 12:16 PM, Joel Bernstein <[email protected]> wrote:
>> I'm pretty confused about points as well and until very recently thought
>> these we geo-spacial improvements only.
>>
>> It would be good to understand the mechanics of points versus numerics. I'm
>> particularly interested in not losing the high performance numeric DocValues
>> support, which has become so important for analytics.
>>
>
> Unrelated. points are the structure used to find matching documents
> from e.g. a query point, range, radius, shape, whatever. They use a
> tree-like structure for this. So the replacement for NumericRangeQuery
> which "simulates" a tree with an inverted index.
>
> Instead of inverted index+postings list, we just have a proper tree
> structure for these things: fixed-width, multidimensional values. It
> has a different indexreader api for example, that lets you control how
> the tree is traversed as it goes (by returning INSIDE [collect all the
> docids in here blindly, this entire tree range is relevant], OUTSIDE
> [not relevant to my query, don't traverse this region anymore], or
> CROSSES [i may or may not be interested, have to traverse further to
> nodes (sub-ranges or values themselves)].
>
> They also have the advantage of not being limited to 64 bits or 1
> dimension, you can have up to 128 bits and up to 8 dimensions. So each
> thing you are adding to your document is really a "point in
> n-dimensional space", so if you want to have 3 lat+long pairs as a
> double[] in a single field, that works as you expect.
>
> See more information here:
> https://github.com/apache/lucene-solr/blob/master/lucene/core/src/java/org/apache/lucene/index/PointValues.java#L35-L79
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to