[
https://issues.apache.org/jira/browse/LUCENE-6198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14316568#comment-14316568
]
Robert Muir commented on LUCENE-6198:
-------------------------------------
I am +1 for this API because it solves my major complaint with the first stab i
took, invasive methods being added to very low level apis.
But i think, on the implementation we should support approximations of
conjunctions like the first patch. I think its important because this way
nested conjunctions/filters work and there is not so much performance pressure
for users to "flatten" things. If we later fix scorers like disjunctionscorer
too, then it starts to have bigger benefits because users can e.g. put
proximity queries or "slow filters" that should be checked last anywhere
arbitrarily in the query, and we always do the right thing.
> two phase intersection
> ----------------------
>
> Key: LUCENE-6198
> URL: https://issues.apache.org/jira/browse/LUCENE-6198
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Robert Muir
> Attachments: LUCENE-6198.patch, LUCENE-6198.patch
>
>
> Currently some scorers have to do a lot of per-document work to determine if
> a document is a match. The simplest example is a phrase scorer, but there are
> others (spans, sloppy phrase, geospatial, etc).
> Imagine a conjunction with two MUST clauses, one that is a term that matches
> all odd documents, another that is a phrase matching all even documents.
> Today this conjunction will be very expensive, because the zig-zag
> intersection is reading a ton of useless positions.
> The same problem happens with filteredQuery and anything else that acts like
> a conjunction.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
