Improve sheduling of min drivers per task

[sopel39]

Start more than single split in TaskExecutor#scheduleTaskIfNecessary.
Previously only single split was started. This caused
that less than task.min-drivers-per-task splits were
running for situations when buffer was underutlized
and no more splits were scheduled by coordinator.

[sopel39]

cc @dain

[losipiuk]

Code LGTM (for what I can tell :) )

Maybe make it more explicit in commit message that it is about target concurrency which is changed while execution. Maybe sht like:

Start more than a single split in TaskExecutor#scheduleTaskIfNecessary.
Previously only a single split was started. This caused
that less than task.min-drivers-per-task splits were
running for situations when targetConcurrency was increased in SplitConcurrencyController.

You mention buffer. What buffery you have in mind?

[sopel39]

You mention buffer. What buffery you have in mind?

It's task output buffer. SplitConcurrencyController adjust concurrency so that buffer is neither empty or full

[arhimondr]

The change looks good to me. The description is a little confusing though.

My understanding is that this method is called when a split is added or when a split is finished. I guess the assumption was that it will always schedule a split if one exist. With this assumption the implementation would behave correctly.

However due to the adaptive concurrency implementation details the pollNextSplit method may not always return a split even if one exist, so the assumption breaks. Thus it is required to schedule as many splits as needed in one shot.

[sopel39]

My understanding is that this method is called when a split is added or when a split is finished. I guess the assumption was that it will always schedule a split if one exist. With this assumption the implementation would behave correctly.

If worker gets N splits, but adaptive task concurrency = N/2 only N/2 splits will start (when all remaining driver slots are already taken by other tasks). In that case in current code when no new splits are received, at most N/2 splits would run until task finishes even if adaptive task concurrency is increased. Basically, I've observed that there happens to be a long tail when query is almost finished and query creeps forward by few splits at a time