gerlowskija commented on PR #2499: URL: https://github.com/apache/solr/pull/2499#issuecomment-2158766213
> Generally "q" is provided by a user, uses a more user-facing query parser (namely edismax), and would be a nice place for such a limit. But otherwise, queries show up in tons of other places for internal use-cases written by systems programmers (i.e. us devs) using the default "lucene" query parser I'm not sure the edismax=user-queries, lucene=system-queries generalization is a safe one to make. And even if it is, I think you're making an additional assumption here that "system" queries wouldn't also benefit from this check. I'm not sure I agree. System-devs are more likely than the average user to know about Solr's performance pitfalls, but is that safe to assume across the board? I think our many years with the project put us in danger of overestimating the knowledge and context other users might have, and underestimating the value of safeguards. That's the key issue for me IMO - if I was more comfortable with those generalizations I'd be happy with an edismax fix. But as-is they feel like pretty shaky ground to base cluster-stability on. > I've only ever increased maxBooleanClauses to something insane, not because there isn't a risk of users doing expensive queries that we want to limit `maxBooleanClauses` is, admittedly, a pain. For one, it's terribly calibrated, or at least terribly out of date. (Is 1024 clauses even a lot on today's hardware? It seems like nothing!). I'm not here to defend it. And I can't speak to the old debate without reading up on it. (Do you have a pointer handy @dsmiley ?) But conceptually I think `maxBooleanClauses` takes the right response to a "DANGER" stimulus. If something has the potential to take down a cluster a global block is the safest thing to do. Solr should be stable by default, even if that means admins have a little extra work to do to "unlock" certain query patterns. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
