Postgres 12, 13, 14 and 15 vs the Insert Benchmark - not many performance regressions, Postgres remains boring (for me).
smalldatum.blogspot.com/2022/06/insert
Conversation
Replying to
I appreciate your work on this - regressions like this matter. The regression in 15 will be investigated soon.
1
8
What's the query for l.i0? I clicked through the description, and didn't quickly find it there. I'm asking because the increase in palloc() suggests the expression has gotten more complicated, but it's hard to know where to look without the query.
And agreed, this is useful!
2
1
I think I might just have found the problem, while on a call with
1
1
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.
2
1
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".
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
Show replies