[ 
https://issues.apache.org/jira/browse/LUCENE-7254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15258053#comment-15258053
 ] 

Robert Muir commented on LUCENE-7254:
-------------------------------------

I will remove the changes from core/: those queries can just continue be bogged 
down by abuse cases. NOTE: just because someone calls newExactQuery() means 
nothing: the value could match a ton of documents. This is not the postings 
list and the way it interacts is different.

For now, point ranges in core will remain slow. But sandbox/ spatial does not 
need to be held back by this: it does not have these problems: we can fix the 
queries I am interested in.

> 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: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to