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

Adrien Grand commented on LUCENE-7880:
--------------------------------------

This is not the only arbitrary limit we have. For instance terms can't be 
greater than 32KB and you can only use edit distances of 1 or 2 with FuzzyQuery.

In some of the cases you mentioned, it seems to me that users should be using 
TermInSetQuery instead. Maybe a few of them actually need scoring, which is 
only provided by BooleanQuery. However, to me those are corner cases, and I 
don't like the idea of extending the API of an important class like 
BooleanQuery just to help deal with corner-cases.

To me the best option is to keep things as they are today: let users know when 
they are using BooleanQuery in ways that won't perform well, yet still allow a 
minority of corner-cases that need greater limits to increase the max clause 
count through the static setter.

> Make boolean query clause limit configurable per-query
> ------------------------------------------------------
>
>                 Key: LUCENE-7880
>                 URL: https://issues.apache.org/jira/browse/LUCENE-7880
>             Project: Lucene - Core
>          Issue Type: Improvement
>            Reporter: Yonik Seeley
>
> As we know, the magic BooleanQuery.maxClauseCount has bitten many people over 
> time.
> It's also a static, which really hurts multi-tenancy (i.e. we can't have 
> different settings for different users, clients, or use-cases).
> If we want to keep this static as a default, then at least we should allow it 
> to be overridden on a per-query basis when we know it is the desired behavior 
> and not a bug.
> Perhaps the simplest way to achieve this would be a setter on 
> BooleanQuery.Builder that configures the limit for that instance only?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Reply via email to