And there's a related issue that could explain the 14 slowdown as well...
The size of ExprEvalStep increased from 64bytes to 88 bytes in 14 and to 296 bytes in 15.
Conversation
I almost always use prepared statements when benchmarking. Maybe this is a sign that I shouldn't always do so, especially with low concurrency benchmarks like the insert benchmark.
2
1
My bias:
1) I rarely used them in my web-scale days
2) With MySQL their usage hasn't been a big boost for perf when I have tried them during sysbench benchmarks
1
I suspect that concurrency control is often the bottleneck with InnoDB (though maybe not with MyRocks). There is seldom much need for an xact to have very many heavyweight lock manager entries in Postgres. No next-key locking, plus row locks are "stored directly in the row".
1
Back in the day, to get the list of currently open transactions (needed by any transaction to determine visibility) was a big perf problem on concurrent workloads. That has improved a lot but I lost track of it.
1
MyRocks has a list of open snapshots, but only compaction has to search it to determine when old versions can be dropped. While I can speculate cases where it will increase CPU too much I have yet to spot that on a benchmark or production workload.
1
I've noticed that being more precise about what versions we'll clean up tends to decrease CPU overhead, even though an increase seemed more likely at first. In a variety of contexts. Seems like this might be related to long version chains having an outsized impact, but not sure.
1
I assume this is mostly with index-access heavy workloads? An unnecessary fetch of a invisible heap version during an index scan is pretty expensive (even just the buffer lookup + locking, not to speak of visibility tests).
2
So it intuitively it makes sense to me that there's a pretty large budget to avoid that. Might be different when measuring just DML? But even there we likely have done a lookup...
1
I'm sure that's all true. I'm speculating that being more precise at the level of "versions per logical row" can have a surprisingly large impact on the *frequency* of opportunistic GC at the page granularity, or perhaps minor compactions with an LSM. Cannot prove this, though.
1
Anything that buys us more space now also buys us more time (until the next GC). But buying more time *also* buys more space in turn, since we'll delete single extra version for rows updated only once. Classic virtuous circle. I suspect that this (and similar effects) do matter.