[
https://issues.apache.org/jira/browse/SOLR-5170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13742738#comment-13742738
]
David Smiley commented on SOLR-5170:
------------------------------------
Hi Rob.
The other DocValues types are a better fit to Solr's API, yes. Assuming each
point is encoded into 8 bytes (2x4 binary encoded floats) and added as a value
with SortedSetDocValuesField, this still means one lookup per point. If there
are a lot of points per document, then the overhead adds up ([as Shai
noted|https://issues.apache.org/jira/browse/LUCENE-4583?focusedCommentId=13652097&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13652097]).
Granted I didn't measure this overhead, but I'd rather SOLR-4329 get
addressed somehow so BinaryDocValues can be used elegantly and then users don't
have to pay an unnecessary price per point dereference.
> Spatial multi-value distance sort via DocValues
> -----------------------------------------------
>
> Key: SOLR-5170
> URL: https://issues.apache.org/jira/browse/SOLR-5170
> Project: Solr
> Issue Type: New Feature
> Components: spatial
> Reporter: David Smiley
> Assignee: David Smiley
> Attachments: SOLR-5170_spatial_multi-value_sort_via_docvalues.patch
>
>
> The attached patch implements spatial multi-value distance sorting. In other
> words, a document can have more than one point per field, and using a
> provided function query, it will return the distance to the closest point.
> The data goes into binary DocValues, and as-such it's pretty friendly to
> realtime search requirements, and it only uses 8 bytes per point.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
