[ https://issues.apache.org/jira/browse/LUCENE-8496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16615249#comment-16615249 ]
Nicholas Knize commented on LUCENE-8496: ---------------------------------------- {quote}It is a pity that the patch is so large{quote} Yeah. Refactoring {{pointDimensionCount}} touched a lot of files so the patch is rather busy. I could change it to leave {{pointDimensionCount}} as is and just add a new {{indexDimensionCount}}? {quote}Out of curiosity, did your working copy already have LUCENE-7862 when you ran the benchmark?{quote} Yes. My benchmark numbers include the latest change to store min/max packed values. The only difference is using {{LatLonShape}} without and with the selective indexing approach. {quote}...could you maybe set up a pull request or use Apache reviewboard{quote} Sure thing! I went ahead and opened a PR [here|https://github.com/apache/lucene-solr/pull/451] > Explore selective dimension indexing in BKDReader/Writer > -------------------------------------------------------- > > Key: LUCENE-8496 > URL: https://issues.apache.org/jira/browse/LUCENE-8496 > Project: Lucene - Core > Issue Type: New Feature > Reporter: Nicholas Knize > Priority: Major > Attachments: LUCENE-8496.patch > > Time Spent: 10m > Remaining Estimate: 0h > > This issue explores adding a new feature to BKDReader/Writer that enables > users to select a fewer number of dimensions to be used for creating the BKD > index than the total number of dimensions specified for field encoding. This > is useful for encoding dimensional data that is used for interpreting the > encoded field data but unnecessary (or not efficient) for creating the index > structure. One such example is {{LatLonShape}} encoding. The first 4 > dimensions may be used to to efficiently search/index the triangle using its > precomputed bounding box as a 4D point, and the remaining dimensions can be > used to encode the vertices of the tessellated triangle. This causes BKD to > act much like an R-Tree for shape data where search is distilled into a 4D > point (instead of a more expensive 6D point) and the triangle is encoded > using a portion of the remaining (non-indexed) dimensions. Fields that use > the full data range for indexing are not impacted and behave as they normally > would. -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org