| From: | Samil C <samillcinar(at)gmail(dot)com> |
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Inquiry Regarding Parallel DML (Write-Side) Support in Future PostgreSQL Releases |
| Date: | 2026-05-22 06:53:49 |
| Message-ID: | CABp-5JGTRDZXyXuQiMkYv=PAtTHJePx=uZOF4kC9=mTs4kwypQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hello PostgreSQL Developers,
I have been analyzing PostgreSQL's parallel execution capabilities and
noticed that parallel query execution is currently available for
operations such as:
Parallel SELECT
CREATE TABLE AS SELECT (CTAS)
Parallel index creation
However, during standard DML operations (INSERT ... SELECT, UPDATE,
DELETE), execution remains effectively single-threaded, preventing the
underlying scans from taking advantage of parallel workers.
I would like to ask whether there are any ongoing discussions or
development plans regarding true parallel DML support in future
PostgreSQL releases. In particular, I am interested in the long-term
direction for parallel execution of INSERT/UPDATE/DELETE operations
and related write-path optimizations.
While I understand the architectural complexities involved in parallel
writes, the current single-threaded execution model remains a
significant bottleneck for large-scale migrations and heavy ETL
workloads.
Until native parallel DML becomes available, are there any recommended
workarounds or best practices for reducing this bottleneck during
large batch operations?
Thank you for your time and for your contributions to PostgreSQL.
Best regards,
SamilC
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Chao Li | 2026-05-22 07:02:48 | Fix pg_get_multixact_stats() members_size calculation |
| Previous Message | solai v | 2026-05-22 06:15:25 | Re: Available disk space per tablespace |