On Sun, Mar 29, 2020 at 4:40 AM Peter Geoghegan <p...@bowt.ie> wrote: > On Sun, Mar 1, 2020 at 12:36 AM Andres Freund <and...@anarazel.de> wrote: > > The workload is a pgbench readonly, with pgbench -M prepared -c $conns > > -j $conns -S -n for each client count. This is on a machine with 2 > > Intel(R) Xeon(R) Platinum 8168, but virtualized. > > > > conns tps master tps pgxact-split > > > > 1 26842.492845 26524.194821 > > 10 246923.158682 249224.782661 > > 50 695956.539704 709833.746374 > > 100 1054727.043139 1903616.306028 > > 200 964795.282957 1949200.338012 > > 300 906029.377539 1927881.231478 > > 400 845696.690912 1911065.369776 > > 500 812295.222497 1926237.255856 > > 600 888030.104213 1903047.236273 > > 700 866896.532490 1886537.202142 > > 800 863407.341506 1883768.592610 > > 900 871386.608563 1874638.012128 > > 1000 887668.277133 1876402.391502 > > 1500 860051.361395 1815103.564241 > > 2000 890900.098657 1775435.271018 > > 3000 874184.980039 1653953.817997 > > 4000 845023.080703 1582582.316043 > > 5000 817100.195728 1512260.802371 > > > > I think these are pretty nice results. > > This scalability improvement is clearly very significant. There is > little question that this is a strategically important enhancement for > the Postgres project in general. I hope that you will ultimately be > able to commit the patchset before feature freeze.
+1, this is really very cool results. Despite this patchset is expected to be clearly a big win on majority of workloads, I think we still need to investigate different workloads on different hardware to ensure there is no regression. ------ Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
