5 ms·

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 tim

• earless1 12y ago
  I agree, if there is proper testing in lower environments which includes data sets that are similar to production then this should not really be necessary. 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.
• adamnemecek 12y ago
  I too found it pretty strange but posted it anyway hoping that someone could maybe give some explanation.
  • showerst 12y ago
    This might be interesting for something like Drupal, where you don't always have control of the queries being generated.
• WALoeIII 12y ago
  Frequently at design time you don't know enough. This is exactly why SQL is great, it is incredibly flexible, it can also allow you to get in your own way, this is just a feature to help detect that.
• hyperpape 12y ago
  Our system allows users to do reporting based on a wide variety of criteria. In general it works, but nothing prevents a user from running queries that will timeout. Timing out is a waste of everyone's time, and it would be better to just kill the request early. 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.
  • hyperpape 12y ago
    In fact, I'll go further: it's basically impossible for our system (and I think it's not an uncommon system for certain types of enterprise software). Part of the structure of the application is that there's a hierarchy representing our customers and their customers or business units. So company A has "sub-companies" (literal sub-companies, business units or customers) B through Z. A query that runs at the sub-company is perfectly acceptable, but excessively expensive at the higher level. Except for the simplest cases, the application has no clue which queries will be problematic. Who knows that information? Only the database.
• bcg1 12y ago
  Just depends on the context... for oltp production environments, might not be so great in a lot of cases. 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.
• clutchski 12y ago
  Never underestimate the need for a pressure release valve in a time of crisis.