Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-21724

Optimize page_cur_insert_rec_low() redo logging

    XMLWordPrintable

Details

    Description

      MDEV-12353 introduces a purely physical redo log format. Some effort was made to optimize page_cur_insert_rec_low(), but it is still writing unnecessarily much log. Here is an example:

      --source include/innodb_page_size_small.inc
      CREATE TABLE t1 (a BIGINT PRIMARY KEY, b LONGBLOB) ENGINE=InnoDB;
      create table t2 (f1 bigint primary key, f2 longblob, f3 longblob,
        index(f2(10), f3(10))) engine=innodb;
      create table t3 (f1 bigint primary key, f2 longblob, f3 longblob,
        index(f2(10), f3(10))) engine=innodb row_format=compressed;
      let $shutdown_timeout=0;
      --source include/restart_mysqld.inc
      DROP TABLE t1,t2,t3;
      

      This test case, which used to fail on the 83rd round when running with the ,4k combination (because it would wrongly apply a mini-transaction whose LSN matches the FIL_PAGE_LSN on the page 0:13, or the only page of SYS_FIELDS) , shows that we are emitting suboptimal redo log records for a particular mini-transaction:

      recv_group_scan_log_recs: ib_log: scan 946527: rec 37 len 8 page 0:13
      recv_group_scan_log_recs: ib_log: scan 946527: rec b9 len 10 page 0:13
      recv_group_scan_log_recs: ib_log: scan 946527: rec b4 len 5 page 0:13
      recv_group_scan_log_recs: ib_log: scan 946527: rec 34 len 5 page 0:13
      recv_group_scan_log_recs: ib_log: scan 946527: rec d5 len 6 page 0:13
      recv_group_scan_log_recs: ib_log: scan 946527: rec b6 len 7 page 0:13
      recv_group_scan_log_recs: ib_log: scan 946527: rec d4 len 5 page 0:13
      recv_group_scan_log_recs: ib_log: scan 946527: rec b0 len 21 page 0:13
      recv_group_scan_log_recs: ib_log: scan 946527: rec 34 len 5 page 0:13
      recv_group_scan_log_recs: ib_log: scan 946527: rec d4 len 5 page 0:13
      recv_group_scan_log_recs: ib_log: scan 946527: rec b3 len 4 page 0:13
      recv_group_scan_log_recs: ib_log: scan 946527: rec 35 len 6 page 0:13
      recv_group_scan_log_recs: ib_log: scan 946527: rec 34 len 5 page 0:13
      

      The decoded form is:

      WRITE(0x28, {0x6, 0xaf, 0x0, 0x28})
      WRITE(0x30, {0x6, 0x94, 0x0, 0x2, 0x0, 0x6, 0x0, 0x1c})
      WRITE(0x4f0, {0x6, 0x94})
      WRITE(0x6e, {0x9})
      MEMMOVE(0x689, {0x6, 0x82, 0xc3}) = from(0x4e7) {0x1b, 0x19, 0x12, 0xc, 0x8, 0x0}
      WRITE(0x68f, {0x1, 0x38, 0xb, 0x0, 0x74})
      MEMMOVE(0x69a, {0x3, 0x82, 0xc3}) = from(0x4f8) {0x1, 0xb2, 0x0}
      WRITE(0x69d, {0x1, 0x0, 0xa, 0x0, 0x0, 0x0, 0x0, 0x6, 0x7e, 0x8d, 0x0, 0x0, 0x3, 0x8a, 0x1, 0xd2, 0x66, 0x33})
      WRITE(0x27, {0x8})
      MEMMOVE(0xfe8, {0x2, 0x2}) = from (0xfea) {0x4, 0x80}
      WRITE(0xfea, {0x4, 0x80})
      WRITE(0x47a, {0x4})
      WRITE(0x6e, {0x5})
      

      • We update the n_owned of the supremum record at 0x6e multiple times.
      • The last MEMMOVE of 2 bytes and WRITE of 2 subsequent bytes could be combined to a single 4-byte WRITE of the page directory, possibly using 4+2 bytes instead of 5+4 bytes.
      • The second-last MEMMOVE of 3 bytes and WRITE of subsequent 18 bytes could be combined to a single record of 21+3 bytes, instead of two records of 5+21 bytes.
      • The WRITE offsets should be in ascending order, so that the same_page encoding can be used.
      • The WRITE to byte 0x27 should be combined with the very first WRITE record to 0x28, using 8+1 bytes instead of 8+5 bytes.

      Attachments

        Issue Links

          Activity

            People

              marko Marko Mäkelä
              marko Marko Mäkelä
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.