Re: ATTACH/DETACH PARTITION CONCURRENTLY

On Thu, Feb 28, 2019 at 3:27 PM Robert Haas <robertmhaas(at)gmail(dot)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