[
https://issues.apache.org/jira/browse/LUCENE-6881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14998830#comment-14998830
]
Michael McCandless commented on LUCENE-6881:
--------------------------------------------
I tested the 1D case as well, just indexing "lat" from the London UK test as an
int, and comparing {{NumericRangeQuery}} with {{DimensionalRangeQuery}}.
Sources are in luceneutil, look for {{IndexAndSearchOpenStreetMaps1D.java}}.
*IntField / NumericRangeQuery*
- 176 sec to index
- 744 MB index on disk
- 14.4 MB in-heap (ramBytesUsed summed across all segments)
- 7.3 sec to run 225 searches (best of 100 iters)
*DimensionalField / DimensionalRangeQuery*
- 363 sec to index
- 472 MB index on disk
- 2.3 MB in-heap (ramBytesUsed summed across all segments)
- 5.4 sec to run 225 searches (best of 100 iters)
So again a slower indexing time, but then a smaller (less so vs. the 2D case)
index, much less heap used, and faster queries.
> Cutover all BKD tree implementations to the codec
> -------------------------------------------------
>
> Key: LUCENE-6881
> URL: https://issues.apache.org/jira/browse/LUCENE-6881
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Fix For: Trunk
>
> Attachments: LUCENE-6881.patch, LUCENE-6881.patch
>
>
> This is phase 4 for enabling indexing dimensional values in Lucene
> ... follow-on from LUCENE-6861.
> This issue removes the 3 pre-existing specialized experimental BKD
> implementations (BKD* in sandbox module for 2D lat/lon geo, BKD3D* in
> spatial3d module for 3D x/y/z geo, and range tree in sandbox module)
> and instead switches over to having the codec index the dimensional
> values.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
