chore(v2): block reader synchronous execution #4122
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
korniltsev
approved these changes
Apr 21, 2025
kolesnikovae
force-pushed
the
chore/block-reader-concurrency
branch
from
0632146 to
74c7f9b
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We currently rely on an adaptive concurrency limiter with gradient-based control to prevent exhausting the resources of query backend instances. While it generally works well, not all queries are equal or comparable, which is necessary for the limiter to be effective. Moreover, intra-block concurrency (e.g., between datasets) introduces significant error into the logic, as resource marshalling increases.
This is a minor change aimed at preventing query backend instances from running OOM: we now synchronize dataset processing. In practice, this means that a query spanning multiple tenant services will process them sequentially within the block context. The vast majority of queries target a single dataset. For the rest, no performance degradation is expected, as most queries are CPU-bound, and concurrency across dataset contexts can actually do more harm than good.
In the future, we should implement proper fair resource allocation management, which will also include admission control.
Even if the query does not have any bounds (such as label filters), the memory consumption is bound by the concurrency we define in the query plan (currently, it's hardcoded to 4):