-
Notifications
You must be signed in to change notification settings - Fork 4.1k
release-25.4: changefeedccl: apply all checkpoints before flushing #163282
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
base: release-25.4
Are you sure you want to change the base?
Conversation
Previously, the checkpoint logic lived in side of the per-span loop. This could result in updating a checkpoint O(spans) times when there is a lagging span in the frontier. This has always been slightly sub-optimal, because we may advance the high water mark multiple times while processing spans, but its particularly costly as of 25.4 because we save individual frontier changes. Release note (performance improvement): improved the performance on changefeed checkpoint when changefeeds are lagging. Informs: #158913
1461c9e to
2b535e7
Compare
|
Thanks for opening a backport. Before merging, please confirm that it falls into one of the following categories (select one):
Add a brief release justification to the PR description explaining your selection. Also, confirm that the change does not break backward compatibility and complies with all aspects of the backport policy. All backports must be reviewed by the TL and EM for the owning area. |
|
It looks like your PR touches production code but doesn't add or edit any test code. Did you consider adding tests to your PR? 🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is dev-inf. |
|
✅ PR #163282 is compliant with backport policy Confidence: high 🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is dev-inf. |
Backport 1/1 commits from #162546 on behalf of @jeffswenson.
Previously, the checkpoint logic lived in side of the per-span loop. This could result in updating a checkpoint O(spans) times when there is a lagging span in the frontier. This has always been slightly sub-optimal, because we may advance the high water mark multiple times while processing spans, but its particularly costly as of 25.4 because we save individual frontier changes.
Release note (performance improvement): improved the performance on changefeed checkpoint when changefeeds are lagging. Informs: #158913
Release justification: fixes a checkpoint performance regression introduced in 25.4.