When queries don't yield cooperatively for long periods of time, say due to blocking sorts and groups, execution control does not add tickets fast enough, or at all.

Imagine a workload where queries take longer than 1 second. The default probing interval is 200ms. We will never observe an increase in throughput even though progress is being made, and thus never increase concurrency.

We should consider the following improvements:

Adjust probing interval based on query latency

If the average query latency is 1 second, we should increase the probing interval to a similar order of magnitude so that our feedback loop captures queries as they complete. But as we scale the probing interval, we should proportionately scale the step size so that we increase tickets with the same velocity as a shorter interval.

Unconditionally add tickets when throughput is zero

If throughput is zero but tickets are maxed out, we should just unconditionally add tickets. When this happens, this means we have many high-latency queries in progress. As long as we have room to increase tickets, this should help ramp up tickets in a "cold start" scenario.