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 1t6nDW-00FZZX-VC for pgsql-general@arkaria.postgresql.org; Fri, 01 Nov 2024 08:41:14 +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 1t6nDV-00BSei-Ay for pgsql-general@arkaria.postgresql.org; Fri, 01 Nov 2024 08:41:13 +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 1t6nDU-00BSea-WD for pgsql-general@lists.postgresql.org; Fri, 01 Nov 2024 08:41:13 +0000 Received: from sm-r-016-dus.org-dns.com ([89.107.70.6]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1t6nDQ-0049Vp-SX for pgsql-general@lists.postgresql.org; Fri, 01 Nov 2024 08:41:12 +0000 Received: from smarthost-dus.org-dns.com (localhost [127.0.0.1]) by smarthost-dus.org-dns.com (Postfix) with ESMTP id C6F9DA21F1 for ; Fri, 1 Nov 2024 09:41:08 +0100 (CET) Received: by smarthost-dus.org-dns.com (Postfix, from userid 1001) id BAD09A21DB; Fri, 1 Nov 2024 09:41:08 +0100 (CET) X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,KAM_INFOUSMEBIZ, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED, SPF_HELO_PASS,SPF_PASS autolearn=no autolearn_force=no version=3.4.6 Received: from ha01s018.org-dns.com (ha01s018.org-dns.com [62.108.32.138]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smarthost-dus.org-dns.com (Postfix) with ESMTPS id 3BF67A21F5 for ; Fri, 1 Nov 2024 09:41:08 +0100 (CET) Authentication-Results: ha01s018.org-dns.com; spf=pass (sender IP is 127.0.0.1) smtp.mailfrom=thiemo@gelassene-pferde.biz smtp.helo=ha01s018.org-dns.com Received-SPF: pass (ha01s018.org-dns.com: connection is authenticated) Received: from [5.83.191.181] ([5.83.191.181]) by webmail.gelassene-pferde.biz (Horde Framework) with HTTPS; Fri, 01 Nov 2024 09:41:06 +0100 Date: Fri, 01 Nov 2024 09:41:06 +0100 Message-ID: <20241101094106.Horde.TwPSs9YUgJ5v-_M-4ltwoeh@webmail.gelassene-pferde.biz> From: thiemo@gelassene-pferde.biz To: PostgreSQL General Subject: Re: Plans for partitioning of inheriting tables References: <5757acdc-39ed-4642-a449-26e47b1bcf95@gelassene-pferde.biz> In-Reply-To: Accept-Language: de Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-PPP-Message-ID: <173045046741.3135531.10322041886405472635@ha01s018.org-dns.com> X-PPP-Vhost: gelassene-pferde.biz X-POWERED-BY: wint.global - AV:CLEAN SPAM:OK List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Adrian Klaver escribió: > It is just not the way you want to do it, see: > > https://www.postgresql.org/docs/current/ddl-partitioning.html#DDL-PARTITIONING-USING-INHERITANCE Thanks for your patience. Maybe I am not clever enough to understand you. I shall try to explain what I try to do. In my project, I have several tables. Each table has some basic technical attributes. For the time being, those are the surrogate key (ID) and a timestamp (ENTRY_PIT) to track the point in time when a record was inserted into the table. To improve consistency and reduce effort, I created a template table those attributes get inherited from by all other tables, e.g. TOPO_FILES. TOPO_FILES can contain GeoTIFF/raster data from different sources. For ease of data management, e.g. wipe all the data of one source, I tried to partition it by SOURCE_ID. And there the error rises that it is not possible to partition a table that is an heir of another table. I feel, you are trying to make me partition TOPO_SOURCES by using inheritance, but I cannot see... now I do see how I could achieve my desires. However, there pop up questions in my mind. To me, it seems, that partitioning using inheritance will not reduce maintenance but greatly increase it. It feels to me very much that I build manually with inheritance, what is done with the partitioning clause. Am I mistaken? In the description, there is the statement that instead of triggers, one could use rules. I am quite sure that, quite a while ago, I was advised in one of the mailing lists against the use of rules other than for inserts as the workings of update and delete rules are almost impenetrable. For me, at least, they were. Are my memories wrong about that? Is there experience on the efficiency/speed comparing partitioning with inheritance using triggers/rules and using the declarative way? I don't think that partition speed is an issue in my case, as I have fairly few records that are in themselves rather big. Remarks to the documentation: - There are examples for the insert path. However, not for the update or delete path. I feel, that those tend to be the more complex ones, especially if my memory is correct about the advice to avoid update and delete rules. - https://www.postgresql.org/docs/current/ddl-partitioning.html#DDL-PARTITIONING-INHERITANCE-MAINTENANCE misses out on a sentence not to forget to adapt the triggers/rules. Kind regards Thiemo