#4430 introduced two new settings:
- max_execution_speed
- max_execution_speed_bytes
Both of which should be very useful in a multi tenant environment, especially as a poor's man non-conserving query prioritization.
When progressImpl is called it checks current execution speed and if it higher than set in settings it sleeps, thus introducing back-pressure to executing threads. (?)
It doesn't seem to work when running aggregations (SELECT count()...) over a cluster (a distributed table). These limits are checked only on the executor node on a progress packet arrival, even though the thread that checked the limit sleeps, the back-pressure is not propagated to leaf nodes as these have no data to push to executor until the whole query is finished.
cc @zhang2014
#4430 introduced two new settings:
Both of which should be very useful in a multi tenant environment, especially as a poor's man non-conserving query prioritization.
When progressImpl is called it checks current execution speed and if it higher than set in settings it sleeps, thus introducing back-pressure to executing threads. (?)
It doesn't seem to work when running aggregations (
SELECT count()...) over a cluster (a distributed table). These limits are checked only on the executor node on a progress packet arrival, even though the thread that checked the limit sleeps, the back-pressure is not propagated to leaf nodes as these have no data to push to executor until the whole query is finished.cc @zhang2014