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]
