On 17/09/2025 8:18 AM, Zhijie Hou (Fujitsu) wrote:
> On Wednesday, September 17, 2025 2:40 AM Konstantin Knizhnik <knizhnik@garret.ru> wrote:
> I think debug_logical_replication_streaming=immediate differs from real parallel
> apply . It wasn't designed to simulate genuine parallel application because it
> restricts parallelism by requiring the leader to wait for each transaction to
> complete on commit. To achieve in-order parallel apply, each parallel apply
> worker should wait for the preceding transaction to finish, similar to the
> dependency wait in the current POC patch. We plan to extend the patch to support
> in-order parallel apply and will test its performance.
You was right.
I tried to preserve commit order with your patch (using my random update
test) and was surprised that performance penalty is quite small:
I run pgbench performing random updates using 10 clients during 100
seconds and then check how long time it takes subscriber to caught up
(seconds):
master: 488
parallel-apply no order: 74
parallel-apply preserve order: 88
So looks like serialization of commits adds not so much overhead and it
makes it possible to use it by default, avoiding all effects which may
be caused by changing commit order at subscriber.
Patch is attached (it is based on your patch) and adds
preserve_commit_order GUC.
