Conversation

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

Replying to

I appreciate your work on this - regressions like this matter. The regression in 15 will be investigated soon.

Replying to

I am happy to repeat tests or provide additional data

Replying to

and

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!

Replying to

and

I think I might just have found the problem, while on a call with

Replying to

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.

Replying to

and

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.

10:44 PM · Jun 16, 2022Twitter Web App

Replying to

and

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

Replying to

and

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