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 1sOXCM-00EiJe-VD for pgsql-general@arkaria.postgresql.org; Tue, 02 Jul 2024 06:41:07 +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 1sOXCL-00629m-3Y for pgsql-general@arkaria.postgresql.org; Tue, 02 Jul 2024 06:41:05 +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 1sOXCK-00629e-Mr for pgsql-general@lists.postgresql.org; Tue, 02 Jul 2024 06:41:05 +0000 Received: from mail-oi1-x231.google.com ([2607:f8b0:4864:20::231]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sOXCE-0000OV-Uy for pgsql-general@lists.postgresql.org; Tue, 02 Jul 2024 06:41:04 +0000 Received: by mail-oi1-x231.google.com with SMTP id 5614622812f47-3d846f4360cso424163b6e.0 for ; Mon, 01 Jul 2024 23:40:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719902456; x=1720507256; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=yi/wQ7Y6C2ht2a1rGaSGax6xnO1jwm9YyNZMnDZ8hd0=; b=LXUPfUbQxabrhi9sVrsEQPNP6CuikeNNliqUzdaDs0TmCOlMLZCmf5BA+nyZseuvd3 7hKQW9R5P9x6LpIdbJpTMBuiRDPaKmNzOXxWwnH6DG2Qka+iJfiqixcuLw9/CBPRq0S5 OqK1EfNALyoKHu+NMKvNjEmbkmOKHwXPOsx51RquXuFbSvywV95qhlTrhaJELl/tS2St +NmJm13LxL3prKSgwWzjApfdliMEUnBc4aWHr6DTSdBiLWYp1hWIP1I3F3uJzGVxDu0X lNS4NSFjYg8WjrL4Tx2wKg+KU7Akxx1vtBIyOvlsS3bfUZgSUcTB6QlnTMecDHM5eht0 wY/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719902456; x=1720507256; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=yi/wQ7Y6C2ht2a1rGaSGax6xnO1jwm9YyNZMnDZ8hd0=; b=MP5tlU1w3TTeqG7fmWVxYpabkwBS+WSlPdk6F2hoSxYOJ7KOGVcHHKcv1Vkf0lkCI8 hukyfxHEssKwWkneUwgsUu8GFxQbHMF3iMTLBNmQkXH8yaLPrpH24/mO6vXPVtBlQ6uM EG/ok+bJ5vkaCA6Z2fiYeRFE843l0q8CLqpvoQXJYpzJHksF2GqoJ8pJOmor4bzjvJYZ tgv6u7r1kZ0CgrIStcSJUB1fLcY1e97RiW2KNZV2y7Pyxg9Bc3ko5d8tTQFJ+g7vwbo9 WZzs8Z1haJ4N21ICz20ijg12sEithPjrRf59bDCuTKaANXabS5s+tPg/qN2xUN5IYJEY H2Xw== X-Gm-Message-State: AOJu0YyGjKu8BBgF5kHCAhoc1TarSQYNHHDpAwLFJvZl8Uve7/whUUb2 2QxYywjWioUO5qrTjEgZNMWRTjtRyVttxC3XwGD0bCVBjPjYETrcgqzSHBe5DFri3T2uukcj39e 1mQKx48XFvpcXT+MmluKyZ86gf1GkhBBZ X-Google-Smtp-Source: AGHT+IFMfELU8FkS6TrGhICopYAoPeCejl41duo4+hVmLcOvZK10GXMa7ggO5dwDfpJoykHNLaiphbXt8Zao4u/2c9U= X-Received: by 2002:a05:6808:1803:b0:3d5:5cd4:5a20 with SMTP id 5614622812f47-3d6b30f52a1mr10546689b6e.19.1719902456314; Mon, 01 Jul 2024 23:40:56 -0700 (PDT) MIME-Version: 1.0 From: yudhi s Date: Tue, 2 Jul 2024 12:10:44 +0530 Message-ID: Subject: Question on partman extension while relation exist To: pgsql-general Content-Type: multipart/alternative; boundary="000000000000f5041d061c3dfe7d" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000f5041d061c3dfe7d Content-Type: text/plain; charset="UTF-8" Hello All, In postgres we are seeing issues during automatic partition maintenance using pg_partman extension. So basically it automatically creates one new partition and drops one historical partition each day based on the set retention period in part_config. We just call it like partman.run_maintenance_proc('table_name'); While there exists foreign key relationships between the partitioned tables, Mainly during dropping the parent partitions it takes a lot of time, as it validates every child table partitions record and also is taking lock longer. Ideally it should check only the respective parent partition, but it's not doing that because the foreign key is defined in table level rather than partition level. So we are planning to create the foreign keys on the partition level but not at table level. And we were thinking of doing it dynamically by having an "event trigger" which will fire on "create statement" i.e while the "create new partition" statement will be triggered by the Pg_partman. It will try to also create the foreign key constraints on the new child partition referring to the respective parent partition during the same time. So that things will be automated. But now we are stuck in one scenario , say for example if we execute the pg_partman for the parent table first then it will create the new partition independently which is fine, but when it will try to drop the historical partition, it will complain stating the child partition already exists. On the other hand, If we run the pg_partman for the child table first, then it will drop the historical child partition without any issue , however it will throw an error while creating the foreign key , as because the respective parent partition has not yet been created. Need advice, how we should handle this scenario. Basically in which order we should call the "pg_partman.run_maintenance_proc" for the parent and child tables? --000000000000f5041d061c3dfe7d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello All,
In postgres we are seeing issues during aut= omatic partition maintenance using pg_partman extension. So basically it au= tomatically creates one new partition and drops one historical partition ea= ch day based on the set retention period in part_config. We just call it li= ke partman.run_maintenance_proc('table_name');

While there e= xists foreign key relationships between the partitioned tables, Mainly duri= ng dropping the parent partitions it takes a lot of time, as it validates e= very child table partitions record and also is taking lock longer. Ideally = it should check only the respective parent partition, but it's not doin= g that because the foreign key is defined in table level rather than partit= ion level. So we are planning to create the foreign keys on the partition l= evel but not at table level.

And we were thinking of doing it dynam= ically by having an "event trigger" which will fire on "crea= te statement" i.e while the "create new partition" statement= will be triggered by the Pg_partman. It will try to also create the foreig= n key constraints on the new child partition referring to the respective pa= rent partition during the same time. So that things will be automated.
<= br>But now we are stuck in one scenario , say for example if we execute the= pg_partman for the parent table first then it will create the new partitio= n independently which is fine, but when it will try to drop the historical = partition, it will complain stating the child partition already exists.
On the other hand,

If we run the pg_partman for the child table= first, then it will drop the historical child partition without any issue = , however it will throw an error while creating the foreign key , as becaus= e the respective parent partition has not yet been created.

Need adv= ice, how we should handle this scenario. Basically in which order we should= call the "pg_partman.run_maintenance_proc" for the parent and ch= ild tables?
--000000000000f5041d061c3dfe7d--