Details
-
Task
-
Status: Open (View Workflow)
-
Minor
-
Resolution: Unresolved
-
None
-
None
Description
The option --binlog-optimize-thread-scheduling was introduced long ago when the binlog group commit code was written. The binlog group commit has an optimization where one thread - the "leader" - does the group commit on behalf of all threads/THDs involved in the group commit. This breaks from the normal connection between thread and THD, and was thus considered potentially risky at the time. So the option was included to allow to disable that optimization in case of problems, and as a means to test the benefit of the optimization, if any:
- https://knielsen-hq.org/w/benchmarking-thread-scheduling-in-group-commit/
- https://knielsen-hq.org/w/benchmarking-thread-scheduling-in-group-commit-part-2/
This was all long time ago, and any problems in other parts of the code related to the optimization should be sorted out by now. So I think the alternate code path serves no useful purpose anymore and could be removed to reduce complexity and save a couple if()'s in a performance-critical part of the code.
That leaves the question of what to do about the option itself. Removing it could cause failures in upgrades if users have the option in their config, though the fix is trivial to just remove the option.
Could also leave the option in as a no-op for backwards compatibility. Possibly deprecating the (no-op) option to remove at a later stage.
Attachments
Issue Links
- is blocked by
-
MDEV-33756 deprecate binlog_optimize_thread_scheduling
- Closed