[ https://issues.apache.org/jira/browse/LUCENE-7254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15258062#comment-15258062 ]
ASF subversion and git services commented on LUCENE-7254: --------------------------------------------------------- Commit 6fa5166e41652fc58a5f18db4796e230b1354dbd in lucene-solr's branch refs/heads/master from [~rcmuir] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=6fa5166 ] LUCENE-7254: (sandbox/ only) Don't let abuse cases slow down spatial queries > DocIDSetBuilder is no good for points > ------------------------------------- > > Key: LUCENE-7254 > URL: https://issues.apache.org/jira/browse/LUCENE-7254 > Project: Lucene - Core > Issue Type: Bug > Reporter: Robert Muir > Attachments: LUCENE-7254.patch, LUCENE-7254.patch > > > For the postings lists, I think this approach works well in dense cases (e.g. > whole DISI's are added, things are coming in order, etc). > However in the points case, it holds back range performance significantly. > There are a couple of problems here: > * expensive cardinality computation (this is a 2% hit) when its totally > unnecessary. we can use index statistics to help here. > * lots of conditional stuff in add(). This includes growing checks / bitset > switching checks and so on (which happens even if you are smart and call > grow, but this stuff all adds up). > I dont think we should try to create a magical shared API that is both > efficient for postings lists of unstructured stuff and at the same time point > collection for structured fields, instead we should just do things > differently for points and iterate from there. -- 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