Not sure the correct choice is to just disable queries at runtime if there performance is a net negative.
Would expect these decisions to be made at design time, or perhaps that alerts are sent to ops when these situations occur.
Would expect these decisions to be made at design time, or perhaps that alerts are sent to ops when these situations occur.
We do try to keep the reporting limited to what can be done efficiently, but I don't know if it's really viable to avoid everything ahead of time.
Except for the simplest cases, the application has no clue which queries will be problematic. Who knows that information? Only the database.
However if you have users building up dynamic queries, etc it might be really nice to fail gracefully if they go overboard, or if there is some temporary condition that is preventing an optimal execution plan. Better than chewing up all of your resources in any case.
I think this could be really helpful in test environments as well.
On the flip side, we have had issues in production that really slowed down our service or even took it down. In those situations it is much more preferable to stop those specific queries than to have the entire service unresponsive.