My first attempt at explaining why Postgres gets more throughput on TPROC-C. The obvious answer -- CPU efficiency. But it will take more time to drill down.
It is interesting that Postgres gets similar throughput with and without stored procedures. But MySQL and MariaDB get a lot more throughput with stored procs enabled.
https://smalldatum.blogspot.com/2026/03/cpu-efficiency-for-mariadb-mysql-and.html
@markcallaghan You posit that "Perhaps the stored prcoedure evaluator in MariaDB and MySQL is more efficient than in Postgres".
Note that the use of stored procedures did reduce the number of context switches with PG. But the after figure still is smaller than mysql/mariadb, with either sp0/1.
Looking at the flame graph for PG it looks like there's not a whole lot CPU time in plpgsql itself, so it just looks like CPU use Isn't the bottleneck?
@markcallaghan Don't get me wrong, plpgsql isn't particularly efficient - I'd not at all been surprised to see that be a bottleneck.
I've certainly seen it be an issue in some hammerdb tests in the past - not helped by hammerdb's plpgsql not being great.
Another aspect is perhaps that hammerdb seems to use plpgsql for both the stored proc and non-stored proc implementation. Note the plpgsql_call_handler() reached in both, just once via CALL and once via an SELECT.
@AndresFreundTec the HammerDB author explained to me that:
* for MySQL and MariaDB, without stored procedures most logic is on the client which sends SQL statements to the DBMS
* for Postgres, it uses functions when stored procedures are disabled so more logic is still on the server
Thus, not seeing a large benefit from enabling stored procs with Postgres might be expected here.
I will update the blog
Mark Callaghan
AndresFreundTec