| From: | Andrei Lepikhov <lepihov(at)gmail(dot)com> |
|---|---|
| To: | "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Parallel Apply |
| Date: | 2025-12-17 11:10:31 |
| Message-ID: | 45138fb7-0413-4ee5-a7c9-d4f970b7f9d2@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 16/12/25 12:35, Hayato Kuroda (Fujitsu) wrote:
> Dear hackers,
>
> 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? Or the WALsender process that decodes WAL records from a
hundred actively committing backends, a bottleneck here?
--
regards, Andrei Lepikhov,
pgEdge
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrey Borodin | 2025-12-17 11:34:09 | Re: Additional message in pg_terminate_backend |
| Previous Message | Zhijie Hou (Fujitsu) | 2025-12-17 11:09:30 | RE: Improve logical replication usability when tables lack primary keys |