| From: | Frédéric Yhuel <frederic(dot)yhuel(at)dalibo(dot)com> |
|---|---|
| To: | Dimitrios Apostolou <jimis(at)gmx(dot)net> |
| 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: ALTER TABLE ADD FOREIGN KEY to partitioned table, is not parallelized |
| Date: | 2025-06-05 14:51:05 |
| Message-ID: | 437f45aa-b6ea-44bc-8dc3-26cfb309be29@dalibo.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On 6/5/25 16:13, Frédéric Yhuel wrote:
>
>
> On 6/4/25 16:12, Dimitrios Apostolou wrote:
>> In general I have noticed most operations are slower after a succesful
>> pg_restore until VACUUM is complete, which is unfortunate as the
>> database is huge and it takes days to run. Something I have on my list
>> to try, is whether a COPY FREEZE would alleviate all this trouble,
>> since all tuples are immediately visible then. Maybe a patch for a new
>> pg_restore option --freeze is a better solution. Are my assumptions
>> right?
>
> It seems that the idea has already been discussed: https://
> www.postgresql.org/message-id/flat/
> CA%2BU5nM%2BXvkUu9ran%2B5cY%3DTWQquLTpvzte4KVMK%3DaDfbr-
> xfNXA%40mail.gmail.com#b61a7fee06e10e61afa68712bc0b3c5b
>
> I've CCed Bruce Mojman, in the hope that he can tell us more about it.
>
>
(It might be more interesting now than 12 years ago thanks to this
patch:
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=7db0cd2145f2bce84cac92402e205e4d2b045bf2)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mark Frost | 2025-06-05 15:42:00 | Poor row estimates from planner, stat `most_common_elems` sometimes missing for a text[] column |
| Previous Message | Frédéric Yhuel | 2025-06-05 14:13:54 | Re: ALTER TABLE ADD FOREIGN KEY to partitioned table, is not parallelized |