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

rocksdb.drop_table2 test takes a lot of time

Details

    Description

      rocksdb.drop_table2 takes nearly a minute to run. On a debug build:

      rocksdb.drop_table2 'write_committed'    [ pass ]  90926
      		 
      rocksdb.drop_table2 'write_prepared'     [ pass ]  92987

      Does it really spend 1.5 minutes doing something useful?

      Attachments

        Activity

          Ascending order - Click to sort in descending order
          psergei Sergei Petrunia added a comment -

          It includes drop_table_repopulate_table.inc which does line-by-line INSERTs. Switching to sequence engine helps a bit:

          rocksdb.drop_table2 'write_committed'    [ pass ]  76029
          		 
          rocksdb.drop_table2 'write_prepared'     [ pass ]  76382

          but not much

          psergei Sergei Petrunia added a comment - It includes drop_table_repopulate_table.inc which does line-by-line INSERTs. Switching to sequence engine helps a bit: rocksdb.drop_table2 'write_committed' [ pass ] 76029 rocksdb.drop_table2 'write_prepared' [ pass ] 76382 but not much
          psergei Sergei Petrunia added a comment -

          Most of the time (one minute) is actually spent in the final wait here:

          set @@global.rocksdb_compact_cf = 'cf1';
          		 
          set @@global.rocksdb_compact_cf = 'rev:cf2';
          		 
          set @@global.rocksdb_compact_cf = 'default';
          		 
           
          		 
          let $show_rpl_debug_info= 1; # to force post-failure printout
          		 
          let $wait_timeout= 300; # Override default 30 seconds with 300.
          		 
          let $wait_condition = select count(*) = 0 
                                as c from information_schema.rocksdb_global_info
          		 
                                where TYPE = 'DDL_DROP_INDEX_ONGOING';
          		 
          --source include/wait_condition.inc

          psergei Sergei Petrunia added a comment - Most of the time (one minute) is actually spent in the final wait here: set @@ global .rocksdb_compact_cf = 'cf1' ; set @@ global .rocksdb_compact_cf = 'rev:cf2' ; set @@ global .rocksdb_compact_cf = 'default' ;   let $show_rpl_debug_info= 1; # to force post-failure printout let $wait_timeout= 300; # Override default 30 seconds with 300. let $wait_condition = select count (*) = 0 as c from information_schema.rocksdb_global_info where TYPE = 'DDL_DROP_INDEX_ONGOING' ; --source include/wait_condition.inc
          psergei Sergei Petrunia added a comment -

          It's the same in upstream. I am not sure if the fact that DDL_DROP_INDEX_ONGOING records are not gone after 1 minute can be considered a bug?

          psergei Sergei Petrunia added a comment - It's the same in upstream. I am not sure if the fact that DDL_DROP_INDEX_ONGOING records are not gone after 1 minute can be considered a bug?

          People

            psergei Sergei Petrunia
            psergei Sergei Petrunia
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:

              Git Integration

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