RE: Parallel Apply

From: "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>
To: 'Andrei Lepikhov' <lepihov(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: RE: Parallel Apply
Date: 2025-12-18 06:44:14
Message-ID: OSCPR01MB149667B8576FA77760785FDCFF5A8A@OSCPR01MB14966.jpnprd01.prod.outlook.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dear Andrei,

> > I have been spending time for benchmarking the patch set. Here is an updated
> > report.
> >
> I apologise if my question is incorrect. But what about asynchronous
> replication? Does this method help to reduce lag?
>
> My case is a replica located far from the main instance. There are an
> inevitable lag exists. Do your benchmarks provide any insights into the
> lag reduction?

Yes, ideally parallel apply can reduce the lag, but note that it affects after
changes are reached to the subscriber. It may not be so effective if lag is
caused by the network. If your transaction is large and you did not enable the
streaming option, changing it to 'on' or 'parallel' can improve the lag.
It allows to replicate changes before huge transactions are committed.

> Or the WALsender process that decodes WAL records from a
> hundred actively committing backends, a bottleneck here?

Can you clarify your use case bit more? E.g., how many instances subscribe the
change from the same publisher. The cheat sheet [1] may be helpful to distinguish
the bottleneck.

[1]: https://wiki.postgresql.org/wiki/Operations_cheat_sheet

Best regards,
Hayato Kuroda
FUJITSU LIMITED

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2025-12-18 06:49:02 Re: [Proposal] Adding Log File Capability to pg_createsubscriber
Previous Message Michael Paquier 2025-12-18 06:35:07 Re: Fwd: [PATCH] Add zstd compression for TOAST using extended header format