-
Notifications
You must be signed in to change notification settings - Fork 1
Latest internal updates #4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Before, only the last 16 bits of the submission_id were used which were in practice nearly always `0`, since there was never more than one submission being generated in the same millisecond (c.f. how Snowflake IDs work). Now, also the higher 64-22=42 bits making up the timestamp are directly involved in the random order, which results in chunks with the same index in different submissions getting wildly different random order numbers.
(Changes are benign; just graph nodes being reordered)
|
@OpsBotPrime merge and tag |
|
Rebased as a2cb5f1, waiting for CI … |
Approved-by: Qqwy Priority: Normal Auto-deploy: false
|
CI job 🟡 started. |
|
The build failed ❌. If this is the result of a flaky test, then tag me again with the |
|
@OpsBotPrime merge and tag |
|
The build failed ❌. If this is the result of a flaky test, then tag me again with the |
|
@OpsBotPrime retry |
Approved-by: Qqwy Priority: Normal Auto-deploy: false
|
Rebased as 6724dd1, waiting for CI … |
|
CI job 🟡 started. |
|
@Qqwy Sorry, I could not tag your PR. Please check the logs |
This PR contains two changes which were done on our internal system but not yet published on the public version.
random_orderis more fair. Before, select chunks of large submissions might sometimes be starved if a queue was very busy.