| From: | Dimitrios Apostolou <jimis(at)gmx(dot)net> |
|---|---|
| To: | Frédéric Yhuel <frederic(dot)yhuel(at)dalibo(dot)com> |
| Cc: | pgsql-performance(at)lists(dot)postgresql(dot)org, bruce(at)momjian(dot)us, Christophe Courtois <christophe(dot)courtois(at)dalibo(dot)com> |
| Subject: | Re: [PATCH] ALTER TABLE ADD FOREIGN KEY to partitioned table, is not parallelized |
| Date: | 2025-06-17 16:23:09 |
| Message-ID: | 4749eb1e-0fd6-f55b-034a-d3c0bbe5ba8b@gmx.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
>
> FWIW I implemented a pg_restore --freeze patch, see attached. It needs
> another patch of mine from [1] that implements pg_restore --data-only
> --clean, which for parallel restores encases each COPY in its own transaction
> and prepends it with a TRUNCATE. All feedback is welcome.
>
> [1] https://www.postgresql.org/message-id/c61263f2-7472-5dd8-703d-01e683421f61%40gmx.net
>
> It works really fast for the data, and I see that some, but not all items
> from section=post-data, start parallel plans. For example I see CREATE INDEX
> spawns parallel workers.
I added it to July's commitfest, mostly to trigger discussion around the
issue.
https://commitfest.postgresql.org/patch/5826/
Not sure how to mark on the commitfest page that the patch requires
another patch from another commitfest entry.
Dimitris
| From | Date | Subject | |
|---|---|---|---|
| Previous Message | Dimitrios Apostolou | 2025-06-13 12:15:17 | Re: Performance implications of 8K pread()s |