Re: Logical replication prefetch
От | Amit Kapila |
---|---|
Тема | Re: Logical replication prefetch |
Дата | |
Msg-id | CAA4eK1LZVoUO-2dSkLckUdPAxo0AE8dcL9GtkuNUMWkohyB1ZA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Logical replication prefetch (Konstantin Knizhnik <knizhnik@garret.ru>) |
Список | pgsql-hackers |
On Sun, Jul 13, 2025 at 5:59 PM Konstantin Knizhnik <knizhnik@garret.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.
В списке pgsql-hackers по дате отправления: