From: | Kirill Reshke <reshkekirill(at)gmail(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Parallel Apply |
Date: | 2025-08-11 08:08:48 |
Message-ID: | CALdSSPjQB2ZGHQi8SAnejL+3FbmWn9+9VAJP-0jwiF3SKCTP5g@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi!
On Mon, 11 Aug 2025 at 09:46, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> Hi,
>
> Background and Motivation
> -------------------------------------
> In high-throughput systems, where hundreds of sessions generate data
> on the publisher, the subscriber's apply process often becomes a
> bottleneck due to the single apply worker model. While users can
> mitigate this by creating multiple publication-subscription pairs,
> this approach has scalability and usability limitations.
>
> Currently, PostgreSQL supports parallel apply only for large streaming
> transactions (streaming=parallel). This proposal aims to extend
> parallelism to non-streaming transactions, thereby improving
> replication performance in workloads dominated by smaller, frequent
> transactions.
Sure.
> Design Overview
> ------------------------
> To safely parallelize non-streaming transactions, we must ensure that
> transaction dependencies are respected to avoid failures and
> deadlocks. Consider the following scenarios to understand it better:
> (a) Transaction failures: Say, if we insert a row in the first
> transaction and update it in the second transaction on the publisher,
> then allowing the subscriber to apply both in parallel can lead to
> failure in the update; (b) Deadlocks - allowing transactions that
> update the same set of rows in a table in the opposite order in
> parallel can lead to deadlocks.
>
Build-in subsystem for transaction dependency tracking would be highly
beneficial for physical replication speedup projects like[0]
>
> Thoughts?
Surely we need to give it a try.
[0] https://github.com/koichi-szk/postgres
--
Best regards,
Kirill Reshke
From | Date | Subject | |
---|---|---|---|
Next Message | John Naylor | 2025-08-11 08:11:21 | Re: [PATCH] Refactor bytea_sortsupport(), take two |
Previous Message | Ajin Cherian | 2025-08-11 08:06:52 | Re: Improve pg_sync_replication_slots() to wait for primary to advance |