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 >>>> >>>> >>> >>
