[
https://issues.apache.org/jira/browse/LUCENE-7845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16037194#comment-16037194
]
ASF subversion and git services commented on LUCENE-7845:
---------------------------------------------------------
Commit 6b022c98f9a1f69de17445004ce8464ee936e51c in lucene-solr's branch
refs/heads/master from [~dsmiley]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=6b022c9 ]
LUCENE-7845: spatial-extras undo optimize; don't consider any rect or circle to
be a point
> spatial RPT optimization when query by point or common date range
> -----------------------------------------------------------------
>
> Key: LUCENE-7845
> URL: https://issues.apache.org/jira/browse/LUCENE-7845
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial-extras
> Reporter: David Smiley
> Assignee: David Smiley
> Fix For: master (7.0)
>
> Attachments: LUCENE_7845_query_by_point_optimization.patch
>
>
> If the query to an RPT index is a 2D point, or if using
> NumerBrangePrefixTreeStrategy / DateRangePrefixTree (Solr DateRangeField) if
> the query is a grid cell (a common date range unit like some particular day),
> then we can do some optimizations, especially if the data is pointsOnly. If
> the data is pointsOnly the strategy can return a TermQuery, if the data isn't
> then we can at least tweak the prefixGridScanLevel. This is motivated by two
> scenarios:
> * indexing polygons and doing lookups by a point (AKA reverse geocoding)
> * indexing date instances and doing date range faceting. Solr's code for this
> has a fast path for a TermQuery, although more is needed beyond this issue to
> get there.
> _This development was funded by the Harvard Center for Geographic Analysis as
> part of the HHypermap project_
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
