Hi, On 2023-10-16 11:04:25 +0300, Anton A. Melnikov wrote: > On 13.10.2023 05:05, Andres Freund wrote: > > Could you provide a bit more details about how you ran the benchmark? The > > reason I am asking is that ~330 TPS is pretty slow for -c20. Even on > > spinning > > rust and using the default settings, I get considerably higher results. > > > > Oh - I do get results closer to yours if I use pgbench scale 1, causing a > > lot > > of row level contention. What scale did you use? > > > I use default scale of 1.
That means you're largely going to be bottlenecked due to row level contention. For read/write pgbench you normally want to use a scale that's bigger than the client count, best by at least 2x. Have you built postgres with assertions enabled or such? What is the server configuration for both versions? > And run the command sequence: > $pgbench -i bench > $sleep 1 > $pgbench -c20 -T10 -j8 I assume you also specify the database name here, given you specified it for pgbench -i? As you're not doing a new initdb here, the state of the cluster will substantially depend on what has run before. This can matter substantially because a cluster with prior substantial write activity will already have initialized WAL files and can reuse them cheaply, whereas one without that activity needs to initialize new files. Although that matters a bit less with scale 1, because there's just not a whole lot of writes. At the very least you should trigger a checkpoint before or after pgbench -i. The performance between having a checkpoint during the pgbench run or not is substantially different, and if you're not triggering one explicitly, it'll be up to random chance whether it happens during the run or not. It's less important if you run pgbench for an extended time, but if you do it just for 10s... E.g. on my workstation, if there's no checkpoint, I get around 633 TPS across repeated runs, but if there's a checkpoint between pgbench -i and the pgbench run, it's around 615 TPS. Greetings, Andres Freund