Funny, I was thinking exactly the same yesterday, after fixing MDEV-23369.

With the MDEV-23369 fix in 10.5, we seem to scale rather well to an insane number of concurrent threads. I tested 1000 connections on a server where nproc reports 56. That would be at least 1033 threads on the server, and at least 1000 more threads for the client workload that was running on the same server.

Yes, there is an inherent limit caused by there being only 128 rollback segments (the component in DB_ROLL_PTR is only 7 bits). The maximum write scalability ought to be reached with innodb_undo_tablespaces=128. But, we do not see a dramatic drop of the total throughput when we add more threads.

Hence, the ‘thread throttling’ at the high level by innodb_thread_concurrency or innodb_commit_concurrency does not seem to make much sense, and those parameters should probably be deprecated and ignored starting with the 10.6 release.

I would deprecate and ignore and hard-wire to 0 the following parameters:

• innodb_thread_concurrency
• innodb_commit_concurrency
• innodb_replication_delay
• innodb_concurrency_tickets
• innodb_thread_sleep_delay
• innodb_adaptive_max_sleep_delay

Also, the column INFORMATION_SCHEMA.INNODB_TRX.trx_concurrency_tickets would become the constant 0.

We will deprecate and ignore these parameters in MariaDB 10.5.5 Server and remove in 10.6, declaring them as MARIADB_REMOVED_OPTION for compatibility with old configuration files.