| From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
|---|---|
| To: | Álvaro Herrera <alvherre(at)kurilemu(dot)de> |
| Cc: | "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, Tomas Vondra <tomas(at)vondra(dot)me>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Andrei Lepikhov <lepihov(at)gmail(dot)com>, wenhui qiu <qiuwenhuifx(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Parallel Apply |
| Date: | 2026-04-17 08:59:21 |
| Message-ID: | CAA4eK1LkOhLdV8VK5jTPDC2xsbYDb8WtndLgsf9a2bdSyCkYQA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Apr 17, 2026 at 11:18 AM Álvaro Herrera <alvherre(at)kurilemu(dot)de> wrote:
>
> I have a quick question about this work -- is there an expectation of
> how quicker parallel apply is, compared to our normal (serial) apply,
> for average cases? Are we talking 20% faster, 2x faster, 10x faster?
>
> (When I say average, I mean not considering fringe cases where the
> workload is such that very little paralelization can be done, and also
> those where you have a contrived case with one thousand parallel
> processes each making progress separately to the point where you get
> ridiculously high numbers. I mean something that can occur in realistic
> workloads.)
>
We did two kinds of tests with the initial patch where it shows good
improvements. (a) logical synchronous replication, the pgbench TPS
improved by up to ~5.5 times, see [1]; (b) Then we measured the
reduction in replication lag which is ~3.5 times, see [2]. Note that
the data is for the initial patch which doesn't preserve commit order
while parallelly applying the transactions and we will reach there in
two steps, (a) the first patch is to allow parallel apply while
preserving commit order, (b) the second patch would be enhancement
atop (a) is to allow parallel apply without preserving commit order.
These are narrow sets of tests on the initial version of patch, we
need to do more elaborate testing once the patch starts to mature. I
don't think we can draw much conclusions from the data of a POC patch
apart from that the work is worth pursuing.
[1] - https://www.postgresql.org/message-id/CABdArM7z8Pi9bYYSFEzz9Li6%2BONSnspXaU0CxVhDmCUZoSagPw%40mail.gmail.com
[2] - https://www.postgresql.org/message-id/CABdArM4gv08OWF5Gxndf8cVgO3MVeU9T8z47sZR%3DrUfL1N9bqw%40mail.gmail.com
--
With Regards,
Amit Kapila.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Chao Li | 2026-04-17 09:17:15 | Re: [PATCH] Compressed TOAST data corruption with REPACK CONCURRENTLY |
| Previous Message | Andrei Lepikhov | 2026-04-17 08:56:34 | A very quick observation of dangling pointers in Postgres pathlists |