Hi Jan, thanks! That helped :-)
On Fri, Dec 2, 2022 at 8:47 AM Jan Høydahl <jan....@cominvent.com> wrote: > A plain q=id:(a b c) is parsed into a boolean query with three SHOULD > clauses, i.e. OR. Try to add &debugQuery=true to a request and see how it > gets parsed. Then if the limit is 1024 you'll get errors above. > > Jan > > > 2. des. 2022 kl. 07:43 skrev michael dürr <due...@gmail.com>: > > > > Thanks to all of you for your advice on using the terms query! I wasn't > > aware of this syntax until now. > > > > Anyways it would be good to know whether I hit a bug or not. > > Are my example queries probably rewritten to something that has more > > boolean clauses? > > If so, why doesn't that apply to the query for the unique key field? > > > > Maybe someone can give some insights here? > > > > Thanks, > > Michael > > > > On Thu, Dec 1, 2022 at 7:45 PM Kevin Risden <kris...@apache.org> wrote: > > > >> > >> > https://solr.apache.org/guide/solr/latest/query-guide/other-parsers.html#terms-query-parser > >> > >> The "!{terms ..." syntax is short for a query parser. Its a terms query > >> parser and as Jan said its way more efficient than boolean clauses for a > >> list of terms. > >> Kevin Risden > >> > >> > >> > >> On Thu, Dec 1, 2022 at 1:04 PM Thomas Heigl <tho...@umschalt.com> > wrote: > >> > >>> 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 <jan....@cominvent.com> > >> 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 <due...@gmail.com>: > >>>>> > >>>>> 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 > >>>> > >>>> > >>> > >> > >
