Now that the design#1 ERRORs have been fixed, we returned to doing performance measuring of the design#1 patch versus HEAD.
Thanks a lot for taking the time to benchmark the patch. It's really helpful.
Publisher "busy" table does commit every 1000 inserts: 2w 4w 8w 16w HEAD 11898 5855 1868 1631 HEAD+v24-0002 21905 8254 3531 1626 %improvement -84% -41% -89% 0%
^ Note - design#1 was slower than HEAD here
~
Publisher "busy" table does commit every 2000 inserts: 2w 4w 8w 16w HEAD 21740 7109 3454 1703 HEAD+v24-0002 21585 10877 4779 2293 %improvement 1% -53% -38% -35%
I assume you meant HEAD+v26-0002 and not v24. I wanted to quickly reproduce these two cases where the patch was significantly worse. Interestingly my results are a bit different than yours.
Publisher "busy" table does commit every 1000 inserts: 2w 4w 8w 16w HEAD 22405 10335 5008 3304 HEAD+v26 19954 8037 4068 2761 %improvement 1% 2% 2% 1%
Publisher "busy" table does commit every 2000 inserts: 2w 4w 8w 16w HEAD 33122 14220 7251 4279 HEAD+v26 34248 16213 7356 3914 %improvement 0% -1% 0% 1%
If I'm not doing something wrong in testing (or maybe the patch doesn't perform reliable yet for some reason), I don't see a drastic change in performance. But I guess the patch is supposed to perform better than HEAD in these both cases anyway. right?. I would expect the performance of the patch to converge to HEAD's performance with large tables. But I'm not sure what to expect when apply worker is busy with large transactions.
However, I need to investigate a bit more what Vignesh shared earlier [1]. It makes sense that those issues can cause this problem here.
It just takes a bit of time for me to figure out these things, but I'm working on it.