[
https://issues.apache.org/jira/browse/LUCENE-7880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16055780#comment-16055780
]
Adrien Grand commented on LUCENE-7880:
--------------------------------------
Rewriting to a TermInSetQuery would not work today since we do not know about
whether scores are needed in rewrite. We might be able to change that though.
Also we'd need to be careful about infinite loops since TermInSetQuery already
rewrites to a BooleanQuery when there are less than 16 terms. I'm a bit torn
about such a rewrite rule since TermInSetQuery can't skip in the general case
(postings are always entirely consumed), so rewriting to it solely based on the
number of clauses feels a bit trappy to me. I think either users should opt in
explicitly for it or we should find a heuristic that can detect when a
TermInSetQuery will perform better than a BooleanQuery with good confidence,
similarly to what we have when it comes to using doc values to execute
ranges/geo queries?
> 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]
