RE: Parallel Apply

Hi hackers,

> Here is the v28 patch set, which addresses all the comments so far, including
> the above and:
>
> * Manu's comments, including one performance bottleneck due to pg_sleep() [1]
> * Vignesh's comments [2][3]
> * Shlok's comments [4]

I ran the benchmark script based on the report, and confirmed skipping pg_usleep()
can significantly improve the performance.

Machine details
----------------
Intel(R) Xeon(R) CPU E5-2690 v4 @ 2.60GHz: 56 cores, 251GiB memory
Ubuntu 24.04 LST, Huge page is enabled.

Source code:
----------------
Three types of sources are prepared:
* HEAD (e9d0600a)
* HEAD + v27 patchset. This would be a baseline.
* HEAD + v27 + skip pg_usleep() in the first try. It's same as what v28 does.

Setup:
---------
Pub --> Sub
- Two nodes created in pub-sub logical replication setup.
- Both nodes have the same set of pgbench tables created with scale=200.
- The sub node is subscribed to all the changes from the pub node's
pgbench tables.

Workload Run:
--------------------
- Disable the subscription on Sub node
- Run default pgbench(read-write) only on Pub node with #clients=8
and each clients run 100000 transactions.
- Enable the subscription on Sub once pgbench completes and then
measure time taken in replication.

Attached script can construct the same setup and workload.

Results:
---------------
Each cell is a median of 5 runs. I found that skipping the sleep significantly
improves the performance.

number of workers v27 [s] v27 + skip pg_usleep() [s]
2 336.03 46.420
4 463.83 42.994
8 664.78 27.616
16 778.81 26.718
32 834.34 26.844
40 844.06 26.025

JFYI, result with HEAD was 56.115 [s]. It meant unconditional sleep could
cause a performance regression, must be avoided.

I'm thinking the brief measurement showed enough information, and upcoming
measurements should be done for v28 and newer.

Best regards,
Hayato Kuroda
FUJITSU LIMITED
> Zhijie Hou