[
https://issues.apache.org/jira/browse/LUCENE-998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12680858#action_12680858
]
Michael McCandless commented on LUCENE-998:
-------------------------------------------
bq. we should get a bit better performance with LUCENE-1483 though, because
each multi-term query will rewrite against each segment
Alas, that was my initial thought too, but it's unfortunately false when you
are not using constant-score rewrite mode.
The rewrite happens in Query.weight(Searcher), which we call once, on the top
level searcher. We then execute the rewritten query per-segment.
I think for a MultiTermQuery that needs to enumerate alot of terms, we are
probably looking at the same problem we saw in LUCENE-1483 with FieldCache
(though of course that enumeration was for all terms).
With constant-score rewrite, we create a filter, and then the filter is only
materialized per-reader.
So, with 2.9, this is another sizable performance benefit/reason to use
constant score rewrite.
> BooleanQuery.setMaxClauseCount(int) is static
> ---------------------------------------------
>
> Key: LUCENE-998
> URL: https://issues.apache.org/jira/browse/LUCENE-998
> Project: Lucene - Java
> Issue Type: Bug
> Components: Search
> Affects Versions: 2.1
> Reporter: Tim Lebedkov
> Attachments: lucene-998.patch
>
>
> BooleanQuery.setMaxClauseCount(int) is static. It does not allow searching in
> multiple indices from different threads using different settings. This
> setting should be probably moved in to the IndexSearcher.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
