[
https://issues.apache.org/jira/browse/LUCENE-6422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley resolved LUCENE-6422.
----------------------------------
Resolution: Fixed
BTW I did a little more benchmarking. For point data there's a nice 10%
improvement or so. Smaller index size too. For non-point data I used pruning
and a distErrPct of 0.025 (default). The recursive prune of RPT on legacy quad
(does more pruning then packed quad) amounted to a 25% smaller index than
PackedQuad, and the index & search were practically the same. I can only
surmise PackedQuad required less memory while indexing, of course. I _suspect_
that if RPT's recursive prune were to do its thing on PackedQuad, PackedQuad
would have a better showing. I'll leave that benchmark to another day. My
experience (& benchmarks) have shown that there is a high correlation between
index size and search, and that pruning helps a ton. Some day I may write a
better recursive prune that doesn't require buffering all tokens.
Thanks again for contributing this Nick!
> Add PackedQuadPrefixTree
> ------------------------
>
> Key: LUCENE-6422
> URL: https://issues.apache.org/jira/browse/LUCENE-6422
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial
> Affects Versions: 5.x
> Reporter: Nicholas Knize
> Assignee: David Smiley
> Fix For: 5.2
>
> Attachments: LUCENE-6422-TRUNK.patch, LUCENE-6422.patch,
> LUCENE-6422.patch, LUCENE-6422.patch, LUCENE-6422.patch, LUCENE-6422.patch,
> LUCENE-6422_with_SPT_factory_and_benchmark.patch
>
>
> This task introduces a PackedQuadPrefixTree that includes two things:
> 1. A packed 8 byte representation for a QuadCell, including more efficient
> implementations of the SPT API than the existing QuadPrefixTree or
> GeoHashPrefixTree.
> 2. An alternative implementation to RPT's "pruneLeafyBranches" that streams
> the cells without buffering them all, which is way more memory efficient.
> However pruning is limited to the target detail level, where it accomplishes
> the most good.
> Future improvements over this approach may include the generation of the
> packed cells using an AutoPrefixAutomaton
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
