[
https://issues.apache.org/jira/browse/LUCENE-4835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13603879#comment-13603879
]
Shawn Heisey commented on LUCENE-4835:
--------------------------------------
Robert's concern didn't occur to me at all, because I reside on the Solr side
of the fence. One approach that might satisfy both sides: 1) Be conservative
in Lucene by leaving the value at 1024 or increasing it to something that would
stress modern hardware. 2) In Solr, explicitly set it to Integer.MAX_VALUE, or
REALLY_BIG_NUMBER so it's less likely to cause overflow problems. If
REALLY_BIG_NUMBER is chosen, we'd probably have to leave maxBooleanClauses
parsing in, but it could be reduced to a commented section in the example
config and could be left out of most of the test configs.
A Lucene user, because they are already in the 'custom code' realm, can
increase the value if they need to, and Solr (which deals in query strings
rather than complex objects) would effectively have the limit removed.
> Raise maxClauseCount in BooleanQuery to Integer.MAX_VALUE
> ---------------------------------------------------------
>
> Key: LUCENE-4835
> URL: https://issues.apache.org/jira/browse/LUCENE-4835
> Project: Lucene - Core
> Issue Type: Improvement
> Affects Versions: 4.2
> Reporter: Shawn Heisey
> Fix For: 5.0, 4.3
>
>
> Discussion on SOLR-4586 raised the idea of raising the limit on boolean
> clauses from 1024 to Integer.MAX_VALUE. This should be a safe change. It
> will change the nature of help requests from "Why can't I do 2000 clauses?"
> to "Why is my 5000-clause query slow?"
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
