On Thu, Feb 28, 2019 at 3:27 PM Robert Haas <robertmh...@gmail.com> wrote: > I'm not currently aware of any remaining correctness issues with this > code, although certainly there may be some. There has been a certain > dearth of volunteers to review any of this. I do plan to poke at it a > bit to see whether it has any significant performance impact, but not > today.
Today, did some performance testing. I created a table with 100 partitions and randomly selected rows from it using pgbench, with and without -M prepared. The results show a small regression, but I believe it's below the noise floor. Five minute test runs. with prepared queries master: tps = 10919.914458 (including connections establishing) tps = 10876.271217 (including connections establishing) tps = 10761.586160 (including connections establishing) concurrent-attach: tps = 10883.535582 (including connections establishing) tps = 10868.471805 (including connections establishing) tps = 10761.586160 (including connections establishing) with simple queries master: tps = 1486.120530 (including connections establishing) tps = 1486.797251 (including connections establishing) tps = 1494.129256 (including connections establishing) concurrent-attach: tps = 1481.774212 (including connections establishing) tps = 1472.159016 (including connections establishing) tps = 1476.444097 (including connections establishing) Looking at the total of the three results, that's about an 0.8% regression with simple queries and an 0.2% regression with prepared queries. Looking at the median, it's about 0.7% and 0.07%. Would anybody like to argue that's a reason not to commit these patches? Would anyone like to argue that there is any other reason not to commit these patches? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
