-
Notifications
You must be signed in to change notification settings - Fork 3.8k
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
changefeedccl: remove changefeed replanning #106595
Conversation
ddf36f3
to
074bf5f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @jayshrivastava)
-- commits
line 29 at r1:
Can you expand this note to indicate that this functionality was disabled by default; and that the change should not impact existing changefeeds in any way.
pkg/ccl/changefeedccl/changefeed_dist.go
line 212 at r1 (raw file):
} var replanChangefeedThreshold = settings.RegisterFloatSetting(
you need to add this setting to the retiredSettings
list in pkg/settings/registry.go
This commit removes changefeed replanning functionality. Initially, this change was to improve the replanning test, which takes 10 seconds to run on average, preventing us from being able to run it under deadlock (see cockroachdb#101894) or stress race. It turns out that the test did not even test replanning based on range distribution, as it used the `ShouldReplan` testing knob to override replanning decisions. After some discussion with @miretskiy, it was decided that it would be better to remove replanning entirely for these reasons: - it's disabled by default - it's not known to be used by any major production clusters or known to show a significant performance improvement - replanning an entire changefeed on a high level is a large hammer. restarting a large changefeed this way will likely cause rows to be re-emitted which may outweigh the benefit of replanning. if we decide to add replanning, it should be more graceful. - the benefit of replanning is not clear (ie. compared to scalability improvements such as reducing CPU usage, goroutine count etc.) Epic: None Closes: cockroachdb#101894 Release note (enterprise change): This change reverts cockroachdb#83143. This removes the settings `changefeed.replan_flow_frequency` and `changefeed.replan_flow_threshold`. These settings were disabled by default and should not affect existing changefeeds in any way.
074bf5f
to
c436ec5
Compare
bors r=miretskiy |
Build succeeded: |
This commit removes changefeed replanning functionality.
Initially, this change was to improve the replanning test, which takes 10 seconds to run on average, preventing us from being able to run it under deadlock (see #101894) or stress race. It turns out that the test did not even test replanning based on range distribution, as it used the
ShouldReplan
testing knob to override replanning decisions. After some discussion with @miretskiy, it was decided that it would be better to remove replanning entirely for these reasons:Epic: None
Closes: #101894
Release note (enterprise change): This change reverts #83143. This removes the settings
changefeed.replan_flow_frequency
andchangefeed.replan_flow_threshold
. These settings were disabled bydefault and should not affect existing changefeeds in any way.