First results when running the standard InnoDB  RQG test suite

innodb_adaptive_hash_index=OFF , innodb_change_buffering=none

RQG runs -- Verdict

    132 -- 'replay'           -- Replay of desired effect (Whitelist match, no Blacklist match)

        0 -- 'interest'         -- Otherwise interesting effect (no Whitelist match, no Blacklist match)

1763 -- 'ignore_*'         -- Effect is not of interest(Blacklist match or STATUS_OK or stopped)

   140 -- 'ignore_stopped'   -- RQG run stopped by rqg_batch because of whatever reasons

        0 -- 'init'             -- RQG run too incomplete (maybe wrong RQG call)

1895 -- Some verdict made.

Total runtime in seconds : 5404

RQG runs started         : 1895

innodb_adaptive_hash_index=ON , innodb_change_buffering=all

RQG runs -- Verdict

      176 -- 'replay'           -- Replay of desired effect (Whitelist match, no Blacklist match)

        0 -- 'interest'         -- Otherwise interesting effect (no Whitelist match, no Blacklist match)

     1710 -- 'ignore_*'         -- Effect is not of interest(Blacklist match or STATUS_OK or stopped)

     135 -- 'ignore_stopped'   -- RQG run stopped by rqg_batch because of whatever reasons

        0 -- 'init'             -- RQG run too incomplete (maybe wrong RQG call)

     1886 -- Some verdict made.

 Total runtime in seconds : 5405

 RQG runs started         : 1886

1. innodb_adaptive_hash_index=ON , innodb_change_buffering=all causes ~ 33% more fails

    than innodb_adaptive_hash_index=OFF , innodb_change_buffering=none.

2. There is in both variants some amount of fails which is caused by known open bugs which are not related to 

     the actual setting of innodb_adaptive_hash_index or they happen outside of InnoDB code.

3. The number of tests performed within to total runtime of ~ 5400s do not allow to conclude if

     innodb_adaptive_hash_index=... gives some advantage in performance or not.

     Reason:

    The tests exited when exceeding the maximum runtime assigned or hitting an error.

    The number of queries which were executed till exit per test is unknown.

    I assume in addition that performance advantages need to be measured with tests which

    emulate some production environment.

    == Far way less DDL and especially not concurrent, for way more DML and especially SELECTs

           + serious bigger tables than the standard InnoDB  RQG test suite uses.

           The purpose of the standard InnoDB  RQG test suite is to hunt bugs and not to emulate some production system.

Known innodb_adaptive_hash_index related bugs

- https://jira.mariadb.org/browse/MDEV-20203 InnoDB: Failing assertion: (block)->index || (block)->n_pointers == 0

- no MDEV yet  InnoDB: Failing assertion: (block)->n_pointers == 0

Both testing variants hit

https://jira.mariadb.org/browse/MDEV-19555 DRAFT: sql/sql_error.h:1036: uint Diagnostics_area::sql_errno() const: Assertion `m_status == DA_ERROR' failed. for CHECK TABLE

but innodb_adaptive_hash_index=ON hits it ~30% more often than OFF.

I am setting resolution to "Done" because

1. The RQG standard test battery for InnnoDB contains since more than one year

     variations of the values assigned to innodb_adaptive_hash_index and

     innodb_change_buffering. And that test battery is used for QA of roughly

     any main and development source tree.

     There was no need to develop special tests.

2. Based  on the extended RQG standard test battery several adaptive hash index

     related bugs were found and fixed since creation of this MDEV in 2019.

- the RQG standard test battery