@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.

@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 Oh, and I'd not expect meaningful effects of AIO in this workload - in 18, the only thing it really might make faster is VACUUM and ANALYZE, and that won't typically matter unless you increase the cost limits substantially...

In 19 we hopefully will get AIO for index scans, which could help some. But it's plausible the cache hit ratio is "too high" for that to matter.

We might also get AIO writes in checkpoints / bgwriter, but I wouldn't expect that to effect the workload much.

@markcallaghan How sure are you that the write stalls are primarily due to vacuum and not due to checkpoints combined with full_page_writes? Would perhaps be interesting to check the effects of either disabling full page writes (not recommended for prod!) or to enable wal_compression=zstd/lz4?

We need to do something about both issues, to be clear....

Small nit about the result pages: Nonzero actually seems to mean NaN or NULL?

@gabrielesvelto Nice thread!

You seem to imply that bugs have become considerably more frequent, largely due to the increased complexity. Right?

To me it's not obvious that the larger number of known issues isn't to a large degree due to much better visibility (we didn't have anywhere close to today's automatic crash collection systems in the past) and due to the vastly increased number of CPUs... Do you have any gut feeling about that?