On Fri, 16 Oct 2020 at 20:12, Peter Geoghegan <p...@bowt.ie> wrote: > The TPS/throughput is about what you'd expect for the two hour run: > > 18,988.762398 TPS for the patch > 11,123.551707 TPS for the master branch.
Very good. > Patch: > > statement latencies in milliseconds: > 0.294 UPDATE pgbench_accounts SET abalance = abalance + > :delta WHERE aid = :aid1; > > Master: > > statement latencies in milliseconds: > 0.604 UPDATE pgbench_accounts SET abalance = abalance + > :delta WHERE aid = :aid1; The average latency is x2. What is the distribution of latencies? Occasional very long or all uniformly x2? I would guess that holding the page locks will also slow down SELECT workload, so I think you should also report that workload as well. Hopefully that will be better in the latest version. I wonder whether we can put this work into a background process rather than pay the cost in the foreground? Perhaps that might not need us to hold page locks?? -- Simon Riggs http://www.EnterpriseDB.com/