| From: | Álvaro Herrera <alvherre(at)kurilemu(dot)de> |
|---|---|
| To: | "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com> |
| Cc: | "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, 'Amit Kapila' <amit(dot)kapila16(at)gmail(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 05:48:12 |
| Message-ID: | aeHIVhNiFtfGss4b@alvherre.pgsql |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hello,
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.)
My point is that if it's 20% faster, it's nice. But if it's, say, 4x
faster, then it's probably groundbreaking to the point that it may
enable new use cases not currently possible.
Thoughts, pointers?
Many thanks
--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
"¿Qué importan los años? Lo que realmente importa es comprobar que
a fin de cuentas la mejor edad de la vida es estar vivo" (Mafalda)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Chao Li | 2026-04-17 06:17:15 | Re: repack: fix a bug to reject deferrable primary key fallback for concurrent mode |
| Previous Message | Fujii Masao | 2026-04-17 05:32:25 | Re: Fix tab completion after EXCEPT (...) in IMPORT FOREIGN SCHEMA |