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

Michael McCandless commented on LUCENE-1252:
--------------------------------------------

bq. I was fairly specific about how to tackle the problem... I dont mean to be 
rude, but did you actually read my proposal?

Yes, you were specific, and yes, I did in fact read the proposal,
several times, and as I said, I like it, but it's a complex problem
that I've also spent time thinking about and so I gave some simple
feedback about an alternative to one part of the proposal:

It just seems strange to me, when Lucene already has this notion of
"boiling down complex queries into their low-level concrete equivalent
queries" (i.e. rewrite) to then add a separate API ("two-phase
execution") for doing what looks to me to be essentially the same
thing.  Two-phase execution is just rewriting to a two-clause
conjunction where the cost of each clause are wildly different,
opening up the freedom for BQ to execute more efficiently.  And,
yes, like rewrite, I think it should "recurse".

I also think BQ should handle the "costly nextDoc" filters (i.e. do
them last) as first class citizens, and it seemed like the proposal
suggested otherwise (maybe I misunderstood this part of the proposal).


> Avoid using positions when not all required terms are present
> -------------------------------------------------------------
>
>                 Key: LUCENE-1252
>                 URL: https://issues.apache.org/jira/browse/LUCENE-1252
>             Project: Lucene - Core
>          Issue Type: Wish
>          Components: core/search
>            Reporter: Paul Elschot
>            Priority: Minor
>              Labels: gsoc2014
>
> In the Scorers of queries with (lots of) Phrases and/or (nested) Spans, 
> currently next() and skipTo() will use position information even when other 
> parts of the query cannot match because some required terms are not present.
> This could be avoided by adding some methods to Scorer that relax the 
> postcondition of next() and skipTo() to something like "all required terms 
> are present, but no position info was checked yet", and implementing these 
> methods for Scorers that do conjunctions: BooleanScorer, PhraseScorer, and 
> SpanScorer/NearSpans.



--
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

Reply via email to