Hi, Kristian! On Jul 04, Kristian Nielsen wrote:
So then, the plan seems to be:
1. I remove the new calls from include/plugin.h, instead place them somewhere not part of a public API (maybe just "extern" declarations inside InnoDB/XtraDB, and whatever is needed to make it work correctly for ha_innodb.dll on Windows).
2. I try to remove the kill-in-background, instead do it directly in the thread doing thd_report_wait_for() (I think that should be possible).
3. I apply the other review comments that you sent in another mail.
4. I file a Jira task for 10.1 about a general solution, with a good API and other ideas collected so far.
Other than this, the patch will be much the same as what I had initially. Is this ok with you? Or did I miss something?
Yes, ok, thanks.
How can T2 run in parallel with T1 if they're from different groups? ... This way, we get more opportunity for parallelism. This optimisation (starting T3/T4 at _start_ of T1/T2 commit, rather than after) is particularly effective when commit is expensive, eg. with --sync-binlog=1 and --innodb-flush-log-at-trx-commit=1. It allows to make effective use of group commit. It also allows to improve parallelism on slaves deeper down in the hierarchy, using --binlog-commit-wait-count. Without this, the group commit parallelism from a slave would always be less than (or equal) to that on the master.
Oh, okay. I didn't know we do that, I thought that - as in the early idea - slave parallelism always follows master's parallelism, and thus can never exceed it. Regards, Sergei