So what you're saying is that an acceptable way to compensate the system's bugginess is by making it more inefficient? I'd rather use a system that's stable under load.

OP has a point [0], though I'm unsure if Kernels under load are really that unstable / untested.

[0] https://brooker.co.za/blog/2021/05/24/metastable.html / https://archive.is/6Qtet

Here the system is doing a pretty consistent 750k TPS instead of oscillating between 0 and 225k-- often sitting near 0TPS for tens of seconds. Which system do you think will have better latency for any given loading?

This is a benchmark that tries to execute as many queries as possible, so the interesting stat is transactions per second, not CPU usage. This benchmark is testing top speed, not real world behaviour.

If you tested both systems with the same workload (eg. a specific number of queries per second), then the average CPU usage would be much lower for the more efficient engine.

The low CPU usage in this benchmark is just a sign that the performance is not CPU bound, but limited by other factors like locking or IO.

A service should use 100% CPU when loaded fully, anything else means you are suffering from bottlenecks that are actively limiting your throughput. Having lower CPU load because your disks are barely hanging in there is certainly not better.

If you want lower max CPU load, just limit its resources (e.g., CPU quota, cpuset limitation) or load it less.