[ https://issues.apache.org/jira/browse/LUCENE-6685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Nicholas Knize updated LUCENE-6685: ----------------------------------- Attachment: LUCENE-6685.patch Updated patch iincludes the following improvements: * Dynamically compute detail level based on query size (includes min/max bounds on detail level) * Remove unnecessary ranges from PointDistanceQuery > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org