Hi Jan,
We ran into the same issue. Terms queries sound like the ideal solution for
our use case, but I couldn't find any documentation on the {!terms} syntax.
Is there anything in the official docs?
Best,
Thomas
On Thu, Dec 1, 2022 at 2:09 PM Jan Høydahl <[email protected]> wrote:
> Have you tried using Terms Query? It is much more efficient than many
> boolean should clauses
>
> ?q={!terms f=id}1 2 3 4...1025
>
> Jan
>
> > 1. des. 2022 kl. 13:27 skrev michael dürr <[email protected]>:
> >
> > Hi,
> >
> > today we updated solr to version 9.1 (lucene version 9.3)
> > Since then we noticed plenty of TooManyNestedClauses in the logs. Our
> > setting for maxClauseCount is 1024
> > I played around a lot and could trace it down to this:
> >
> > * I built an index from scratch with two fields (id is unique key) and
> > luceneMatchVersion 9.3:
> >
> > <field name="id" type="string_dv" indexed="true" stored="true"
> > multiValued="false" required="true"/>
> > <field name="createdById" type="p_long_dv" indexed="true" stored="false"
> > multiValued="false" />
> >
> > <fieldType name="string_dv" class="solr.StrField" sortMissingLast="true"
> > omitNorms="true" docValues="true" />
> > fieldType name="p_long_dv" class="solr.LongPointField" docValues="true"
> > omitNorms="true" />
> >
> > As expected this works (the dots(...) represent the complete set of
> numbers
> > up to 1024):
> >
> > curl -XGET http://localhost:8983/solr/myindex/select?q=+id:(1 2 3 ...
> 1024)
> >
> > And this fails:
> >
> > curl -XGET http://localhost:8983/solr/myindex/select?q=+id:(1 2 3 ...
> 1025)
> >
> > But when I use the other field (categoryId) this fails:
> >
> > curl -XGET http://localhost:8983/solr/myindex/select?q=+categoryId:(1 2
> 3
> > ... 1024)
> >
> > It works until 512 and starts failing from 513 clauses
> >
> > No difference when doing it like this:
> >
> > curl -XGET http://localhost:8983/solr/myindex/select?q=+(categoryId:1
> > categoryId:2 ... categoryId:1024)
> >
> > Am I misunderstanding the limit maxClauseCount?
> >
> > I'm pretty sure that we did not have any issues with this before.
> >
> > Thanks,
> > Michael
>
>
