Right, but when the size is 100MB, it seems to be taking a bit more
time. Do we want to evaluate with different sizes to see how it looks?
Other than that all the numbers are good.
I did a similar testing with again 100MB and also 1GB this time.
| 100 MB | 1 GB
----------------------------------------------------------
master | 14761.425 ms | 160932.982 ms
----------------------------------------------------------
patch | 14398.408 ms | 160593.078 ms
This time, it seems like the patch seems slightly faster than the master.
Not sure if we can say the patch slows things down (or speeds up) if the size of tables increases.
The difference may be something arbitrary or caused by other factors. What do you think?
I also wondered what happens when "max_sync_workers_per_subscription" is set to 1.
Which means tablesync will be done sequentially in both cases but the patch will use only one worker and one replication slot during the whole tablesync process.
Here are the numbers for that case:
| 100 MB | 1 GB
----------------------------------------------------------
master | 27751.463 ms | 312424.999 ms
----------------------------------------------------------
patch | 27342.760 ms | 310021.767 ms
Best,
