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.96) (envelope-from ) id 1wd6n7-003tRF-2j for pgsql-hackers@arkaria.postgresql.org; Fri, 26 Jun 2026 13:40:21 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wd6n6-00BHXN-2G for pgsql-hackers@arkaria.postgresql.org; Fri, 26 Jun 2026 13:40:20 +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.96) (envelope-from ) id 1wd6n6-00BHXB-1J for pgsql-hackers@lists.postgresql.org; Fri, 26 Jun 2026 13:40:20 +0000 Received: from charmander.telsasoft.com ([50.244.222.1] helo=pryzbyj2023.telsasoft) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wd6n4-00000000MdJ-1bBY for pgsql-hackers@lists.postgresql.org; Fri, 26 Jun 2026 13:40:20 +0000 Received: by pryzbyj2023.telsasoft (Postfix, from userid 1000) id 7AAC83BC1; Fri, 26 Jun 2026 08:40:14 -0500 (CDT) Date: Fri, 26 Jun 2026 08:40:14 -0500 From: Justin Pryzby To: Alexander Korotkov Cc: Pavel Borisov , Dmitry Koval , Alexander Lakhin , pgsql-hackers@lists.postgresql.org, Tomas Vondra , Alvaro Herrera Subject: Re: Add SPLIT PARTITION/MERGE PARTITIONS commands Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Thanks for addressing the tablespace issue. One more thing -- merging non-contiguous tables is currently refused: ts=# CREATE TABLE a(t timestamptz) PARTITION BY RANGE (t); ts=# CREATE TABLE a_20260101 PARTITION OF a FOR VALUES FROM ('20260101')TO('20260102'); ts=# CREATE TABLE a_20260126 PARTITION OF a FOR VALUES FROM ('20260126')TO('20260127'); ts=# CREATE TABLE a_20260127 PARTITION OF a FOR VALUES FROM ('20260127')TO('20260128'); ts=# CREATE TABLE a_20260128 PARTITION OF a FOR VALUES FROM ('20260128')TO('20260129'); ts=# ALTER TABLE a MERGE PARTITIONS (a_20260101,a_20260126,a_20260127,a_20260128) INTO a_202601; ERROR: cannot merge partition "a_20260126" together with partition "a_20260101" DETAIL: The lower bound of partition "a_20260126" is not equal to the upper bound of partition "a_20260101". HINT: ALTER TABLE ... MERGE PARTITIONS requires the partition bounds to be adjacent. The goal seems to be to avoid overlapping partition constaints. If there's a default partition, that also avoids the possibility of needing to move *some* (but not all) tuples from it into the merged partition. I think there should be separate logic depending on the existance of a default partition: - The existing logic seems to correctly handle the case of a default partition, which is being merged (gap is allowed). - The case of a default partition which is not being merged is also handled: no gap is allowed. Actually, this case was probably the motivation behind checking that the partitions are adjacent. - If there's *no* default partition, then I think the check should be relaxed; it's sufficient to verify that the bounds of the merged partition do not overlap with any partition which is not being merged; -- Justin