Re: Logical replication prefetch

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Konstantin Knizhnik <knizhnik(at)garret(dot)ru>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Logical replication prefetch
Date: 2025-07-14 09:53:47
Message-ID: CAA4eK1LZVoUO-2dSkLckUdPAxo0AE8dcL9GtkuNUMWkohyB1ZA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Jul 13, 2025 at 5:59 PM Konstantin Knizhnik <knizhnik(at)garret(dot)ru> wrote:
>
>
> Certainly originally intended use case was different: parallel apply is
> performed only for large transactions. Number of of such transactions is
> not so big and
> so there should be enough parallel apply workers in pool to proceed
> them. And if there are not enough workers, it is not a problem to spawn
> new one and terminate
> it after completion of transaction (because transaction is long,
> overhead of spawning process is not so larger comparing with redo of
> large transaction).
>

Right.

> But if we want to efficiently replicate OLTP workload, then we
> definitely need some other approach.
>

Agreed, for simplicity, for now we can have a GUC to decide the size
of the pool. There is a note in the code for this as well, see: " XXX
This worker pool threshold is arbitrary and we can provide a GUC
variable for this in the future if required. I think we can think of
some dynamic strategy where we remove from the pool if the workers are
not in use for some threshold period of time or something on those
lines. But at this stage it is better to use something simple and try
to come up with a good way to perform pre-fetch or parallelization of
short transactions.

--
With Regards,
Amit Kapila.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message suyu.cmj 2025-07-14 09:57:18 Re: The same 2PC data maybe recovered twice
Previous Message Amit Kapila 2025-07-14 09:43:18 Re: Logical replication prefetch