Bug #99948 btr_attach_half_pages don't need to set prev_block or next_block
Submitted: 21 Jun 2020 22:23 Modified: 22 Jun 2020 12:25
Reporter: Zongzhi Chen (OCA) Email Updates:
Status: Verified Impact on me:
None 
Category:MySQL Server: InnoDB storage engine Severity:S3 (Non-critical)
Version:8.0 OS:Any
Assigned to: CPU Architecture:Any

[21 Jun 2020 22:23] Zongzhi Chen
Description:
In btr_attach_half_pages function()

It is in the middle step of InnoDB SMO. InnoDB try to link the page(p1), and new_page(p2) to page's prev_page(p3) and next_page(p4).

However, if the direction is FSP_UP, it only need the set the p4's prev_page to new page(p2), and don't need to set the p3's next_page to p1, since it don't change p1.

There is same waste operation when the direction is FSP_DOWN..

I suggest to remove the waste operation..

How to repeat:
read the code..

Suggested fix:
I have modify the code and running, even there is almost non performance optimization, at lease it running well..

@@ -2171,7 +2171,7 @@ static void btr_attach_half_pages(

   /* Update page links of the level */

-  if (prev_block) {
+  if (prev_block && direction == FSP_DOWN) {
 #ifdef UNIV_BTR_DEBUG
     ut_a(page_is_comp(prev_block->frame) == page_is_comp(page));
     ut_a(btr_page_get_next(prev_block->frame, mtr) == block->page.id.page_no());
@@ -2181,7 +2181,7 @@ static void btr_attach_half_pages(
                       buf_block_get_page_zip(prev_block), lower_page_no, mtr);
   }

-  if (next_block) {
+  if (next_block && direction != FSP_DOWN) {
 #ifdef UNIV_BTR_DEBUG
     ut_a(page_is_comp(next_block->frame) == page_is_comp(page));
     ut_a(btr_page_get_prev(next_block->frame, mtr) == page_get_page_no(page));
[21 Jun 2020 22:41] Zongzhi Chen
After runing many times of sysbech oltp_insert, there is about 2% performance optimization...

before the fix:
SQL statistics:
    queries performed:
        read:                            0
        write:                           1417911
        other:                           0
        total:                           1417911
    transactions:                        1417911 (14172.55 per sec.)
    queries:                             1417911 (14172.55 per sec.)
    ignored errors:                      0      (0.00 per sec.)
    reconnects:                          0      (0.00 per sec.)

General statistics:
    total time:                          100.0443s
    total number of events:              1417911

Latency (ms):
         min:                                    0.13
         avg:                                   18.06
         max:                                  899.72
         95th percentile:                      108.68
         sum:                             25603694.01

Threads fairness:
    events (avg/stddev):           5538.7148/174.79
    execution time (avg/stddev):   100.0144/0.01

after the patch:
SQL statistics:
    queries performed:
        read:                            0
        write:                           1442132
        other:                           0
        total:                           1442132
    transactions:                        1442132 (14415.49 per sec.)
    queries:                             1442132 (14415.49 per sec.)
    ignored errors:                      0      (0.00 per sec.)
    reconnects:                          0      (0.00 per sec.)

General statistics:
    total time:                          100.0384s
    total number of events:              1442132

Latency (ms):
         min:                                    0.13
         avg:                                   17.75
         max:                                  894.51
         95th percentile:                      108.68
         sum:                             25602354.60

Threads fairness:
    events (avg/stddev):           5633.3281/183.16
    execution time (avg/stddev):   100.0092/0.01
[22 Jun 2020 12:27] MySQL Verification Team
Hi Mr. zongzhi,

Thank you for your bug report.

I have analysed your patch and I agree with you.

Verified as reported.