[
https://issues.apache.org/jira/browse/LUCENE-6685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14637152#comment-14637152
]
Nicholas Knize commented on LUCENE-6685:
----------------------------------------
In the spirit of [~mikemccand] demonstration video for BKD I have posted a
[youtube video|https://youtu.be/l2zB9TDUAL4] demonstrating GeoPointField's
generation of morton numeric ranges computed from a GeoPointDistanceQuery using
the most recent patch. The detail level is computed dynamically based on query
size. This trades memory consumption for potentially visiting more detail
terms. I plan on adding an enhancement making this level user configurable
giving more control over the query performance (not to be confused with
accuracy).
> GeoPointInBBox/Distance queries should have safeguards
> ------------------------------------------------------
>
> Key: LUCENE-6685
> URL: https://issues.apache.org/jira/browse/LUCENE-6685
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Michael McCandless
> Fix For: 5.3, Trunk
>
> Attachments: LUCENE-6685.patch, LUCENE-6685.patch, LUCENE-6685.patch
>
>
> These queries build a big list of term ranges, where the size of the list is
> in proportion to how many cells of the space filling curve are "crossed" by
> the perimeter of the query (I think?).
> This can easily be 100s of MBs for a big enough query ... not to mention slow
> to enumerate (we still do this again for each segment).
> I think the queries should have safeguards, much like we have
> maxDeterminizedStates for Automaton based queries, to prevent accidental
> OOMEs.
> But I think longer term we should either change the ranges to be enumerated
> on-demand and never stored in entirety (like NumericRangeTermsEnum), or
> change the query so it has a fixed budget of how many cells it's allowed to
> visit and then within a crossing cell it uses doc values to post-filter.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
