Does this actually work? This individual ID matching feels very fragile attempt at enforcing the sort order and maybe represents an architectural issue. Maybe you need to do some joins or graph walking instead. Or, more likely, you would benefit from over-fetching and just sorting on the ids on the frontend, since you have those IDs already. You are over-fetching already anyway (rows=250), so you don't seem to worry that much about payload size.
But, apart from that: 1) Switch from GET to POST 2) 'fl' field list and others after it are probably not very mutable, this can go into defaults for the request handler (custom one perhaps) 3) You don't seem to use filter queries. But you also have a lot of binary flags that may benefit from being pushed into 'fq' and improve caching/minimize score calculations. You could also have not-cached FQs if you think they will not be reused 4) If you have sets of params that repeat often but not always, you could do some variable substitutions to loop them in with paramSets 5) Move the sorting query into a boost query, just for clarity of intent Regards, Alex. On Tue, 19 May 2020 at 10:16, vishal patel <vishalpatel200...@outlook.com> wrote: > > > Which query parser is used if my query length is large? > My query is > https://drive.google.com/file/d/1P609VQReKM0IBzljvG2PDnyJcfv1P3Dz/view > > > Regards, > Vishal Patel
