Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uNBM1-00DkmJ-Ni for pgsql-performance@arkaria.postgresql.org; Thu, 05 Jun 2025 14:14:01 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1uNBLz-009ktt-Hk for pgsql-performance@arkaria.postgresql.org; Thu, 05 Jun 2025 14:14:00 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uNBLz-009ktl-7J for pgsql-performance@lists.postgresql.org; Thu, 05 Jun 2025 14:13:59 +0000 Received: from mail1.dalibo.net ([51.159.93.128] helo=mail.dalibo.com) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1uNBLx-000N7I-1v for pgsql-performance@lists.postgresql.org; Thu, 05 Jun 2025 14:13:59 +0000 Received: from [192.168.0.7] (5-49-10-71.hfc.dyn.abo.bbox.fr [5.49.10.71]) by mail.dalibo.com (Postfix) with ESMTPSA id 2AEB725FB2; Thu, 5 Jun 2025 16:13:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dalibo.com; s=a; t=1749132835; bh=xWL+UGYG1fxit+HxVwcNpb1vtLlk8g5iKu6bJCsCQAk=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=AsezAOt9kMwP5cmTBz+XijRZSs5QcWEWgKw0eWKSQ/84Evl95Iu0mAXJFpSBPj8s0 djrgVuU6Uv1ymadAd54Vgde1bLrcDbisi+lK+7BcuA6ICxgLbLtv+ynaMfLradqAEU pLKC5OMixqVSaRxB2jiel1LK9ZjNarRtIayI9ArE= Message-ID: <90e55c6b-3d79-4bf8-8874-a64dd10a0286@dalibo.com> Date: Thu, 5 Jun 2025 16:13:54 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: ALTER TABLE ADD FOREIGN KEY to partitioned table, is not parallelized To: Dimitrios Apostolou Cc: pgsql-performance@lists.postgresql.org, bruce@momjian.us, Christophe Courtois References: <5f002654-92e9-8032-3e1a-134461b4e819@gmx.net> From: =?UTF-8?Q?Fr=C3=A9d=C3=A9ric_Yhuel?= Content-Language: fr, en-US Autocrypt: addr=frederic.yhuel@dalibo.com; keydata= xjMEXn3bgxYJKwYBBAHaRw8BAQdA6tX5FT/n5ztMWIoBdl6k5avvu65fv6ryfVzIx/aH3V3N JEYuIFlodWVsIDxmcmVkZXJpYy55aHVlbEBkYWxpYm8uY29tPsKWBBMWCAA+FiEEi7OTyf6H ePS+C6n11XGWhN8zGNUFAmZDVJ8CGwMFCQtfi90FCwkIBwIGFQoJCAsCBBYCAwECHgECF4AA CgkQ1XGWhN8zGNV65gEA6o+UrebFjn2CIAOYwP3CiiJugiM5TMH9yJyehQua5ZoA/2ChxiVn 8OUaAw/ErxJmQi1mSN0tNZBL/KhkUPBDUDQNzjgEXn3bgxIKKwYBBAGXVQEFAQEHQCuh5cLQ AtEBXHa2Fmtp0kduBu7msM7qO/gaEcdjFUdiAwEIB8J+BBgWCAAmAhsMFiEEi7OTyf6HePS+ C6n11XGWhN8zGNUFAmZDVJ8FCQtfi90ACgkQ1XGWhN8zGNWOOAEArSqePBqfd4Kx4ulACaWO 6fM+XSDfUlBAQXx9rU6DR4MBALwozl9g91tRysim6lKxggvBfp/PvbpTZNrxYLWB2fYP In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk 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.