[ https://issues.apache.org/jira/browse/LUCENE-6198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14290527#comment-14290527 ]
Michael McCandless commented on LUCENE-6198: -------------------------------------------- Is an approximation itself allowed to have another approximation? This could solve the +"the zoo" +"the boy" case, I think ... because "the zoo" would rewrite to: {noformat} +the +zoo "the zoo" {noformat} and then the +the +zoo would rewrite to: {noformat} +zoo +the {noformat} Then it's not until there's global agreement about zoo's next doc, that we would even all advance on the? Or maybe we simply disallow recursive approximations for starters? I do like that the current patch is a baby step that looks like it can succeed :) > 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 > > > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org