Venkat, There is another way to do this. If you have a category of "thing" you are attempting to filter over, then you create a query and tag the documents with this category. So, create a 'categories' field and append 'thing' to the field updating the field if need be. (Be wary of over generation if one of the categories turns out to be 'thin').
Then in the filter query you can query over a category, or simply require a category:thing to be in the query. tim On Thu, May 30, 2019 at 3:33 PM Shawn Heisey <apa...@elyograg.org> wrote: > On 5/30/2019 4:13 PM, Venkateswarlu Bommineni wrote: > > Thank you guys for quick response. > > > > I was able to query solr by sending 1500 products using solrJ with http > > post method. > > > > But I had to change maxBooleanClauses to 4096 from default 1024. > > > > But I wanted to check with you guys that, will there be any performance > > issues by changing maxBooleanClauses to 4096. > > Please help me here. > > Lucene sets the limit to 1024 basically to act as a short-circuit to > protect the system against bugs in user code causing the query engine to > explode by sending thousands of clauses when that wasn't what was intended. > > Using a large number of clauses *can* cause performance issues. But if > you need to use them, you need to use them, and in that case you'll need > to increase the limit, and just take the performance hit. > > The terms query parser will generally run faster than a large number of > boolean OR clauses, and return the same results. But if your query is > not just OR (also known as SHOULD) clauses, you probably won't be able > to use the terms parser. > > > https://lucene.apache.org/solr/guide/7_7/other-parsers.html#terms-query-parser > > Thanks, > Shawn >
