On Mon, Mar 18, 2019 at 7:34 PM Peter Geoghegan <p...@bowt.ie> wrote: > With pgbench scale factor 20, here are results for patch and master > with a Gaussian distribution on my 8 thread/4 core home server, with > each run reported lasting 10 minutes, repeating twice for client > counts 1, 2, 8, 16, and 64, patch and master branch: > > 1 client master: > tps = 7203.983289 (including connections establishing) > 1 client patch: > tps = 7012.575167 (including connections establishing) > > 2 clients master: > tps = 13434.043832 (including connections establishing) > 2 clients patch: > tps = 13105.620223 (including connections establishing)
Blech. I think the patch has enough other advantages that it's worth accepting that, but it's not great. We seem to keep finding reasons to reduce single client performance in the name of scalability, which is often reasonable not but wonderful. > However, this isn't completely > free (particularly the page split stuff), and it doesn't pay for > itself until the number of clients ramps up. I don't really understand that explanation. It makes sense that more intelligent page split decisions could require more CPU cycles, but it is not evident to me why more clients would help better page split decisions pay off. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
