Description:
Situation
---------
The thread keeps a pending RBR event available, where new rows can be added on execution of ``ha_*_row()`` functions. Each time a row is about to be added, the ``check_table_replication_row_based()`` function is called to check if the current pending event needs to be flushed to the binary log and a new pending event constructed. The function definition in it's entirety is::
static bool
check_table_replication_row_based(TABLE *table)
{
return
opt_binlog_row_based_logging &&
table->s->tmp_table == NO_TMP_TABLE &&
rpl_filter->db_ok(table->s->db) &&
rpl_filter->db_ok_with_wild_table(table->s->db) &&
strcmp(table->s->db, "mysql") != 0;
}
Problem
-------
This function is called each time a row is added, which is a lot of times. Especially note that all condition are evaluated whenever the row *can* be added to the current pending event, so there's a lot of cycles wasted here.
How to repeat:
Run with --binlog-format=row --debug and inspect execution trace.
Suggested fix:
The following solution was suggested by Guilhem: since the test is entirely based on the status of the table, the result of one execution of the function can be cached in the table structure [e.g., as ``table->rbr_cond_checked`` /Matz].
Description: Situation --------- The thread keeps a pending RBR event available, where new rows can be added on execution of ``ha_*_row()`` functions. Each time a row is about to be added, the ``check_table_replication_row_based()`` function is called to check if the current pending event needs to be flushed to the binary log and a new pending event constructed. The function definition in it's entirety is:: static bool check_table_replication_row_based(TABLE *table) { return opt_binlog_row_based_logging && table->s->tmp_table == NO_TMP_TABLE && rpl_filter->db_ok(table->s->db) && rpl_filter->db_ok_with_wild_table(table->s->db) && strcmp(table->s->db, "mysql") != 0; } Problem ------- This function is called each time a row is added, which is a lot of times. Especially note that all condition are evaluated whenever the row *can* be added to the current pending event, so there's a lot of cycles wasted here. How to repeat: Run with --binlog-format=row --debug and inspect execution trace. Suggested fix: The following solution was suggested by Guilhem: since the test is entirely based on the status of the table, the result of one execution of the function can be cached in the table structure [e.g., as ``table->rbr_cond_checked`` /Matz].