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

Robert Muir commented on LUCENE-3328:
-------------------------------------

{quote}
I disagree here, if this would be the case it should be called simplify(Query). 
In general its a rewrite method and should not be judged if it simplifies or 
not. 
{quote}

I think this is really important to hash out: if we want to optimize query 
execution, we should do this totally internally at the lowest level possible.
If the optimization is to use a specialized scorer, then I think the right 
place to do this is inside the Weight.

I don't think we should create a bunch of queries that are really the same and 
rewrite to each other: because this is more 'exposed' to end users, e.g.
highlighting, caching, and who knows what people are doing in their custom code.

It also requires a heavy maintenance burden of duplicate logic and testing for 
explain, hashcode, equals, etc.


> Specialize BooleanQuery if all clauses are TermQueries
> ------------------------------------------------------
>
>                 Key: LUCENE-3328
>                 URL: https://issues.apache.org/jira/browse/LUCENE-3328
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: core/search
>    Affects Versions: 3.4, 4.0
>            Reporter: Simon Willnauer
>             Fix For: 3.4, 4.0
>
>         Attachments: LUCENE-3328.patch, LUCENE-3328.patch
>
>
> During work on LUCENE-3319 I ran into issues with BooleanQuery compared to 
> PhraseQuery in the exact case. If I disable scoring on PhraseQuery and bypass 
> the position matching, essentially doing a conjunction match, 
> ExactPhraseScorer beats plain boolean scorer by 40% which is a sizeable gain. 
> I converted a ConjunctionScorer to use DocsEnum directly but still didn't get 
> all the 40% from PhraseQuery. Yet, it turned out with further optimizations 
> this gets very close to PhraseQuery. The biggest gain here came from 
> converting the hand crafted loop in ConjunctionScorer#doNext to a for loop 
> which seems to be less confusing to hotspot. In this particular case I think 
> code specialization makes lots of sense since BQ with TQ is by far one of the 
> most common queries.
> I will upload a patch shortly

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to