MIME-Version: 1.0
References: <ZkN6EfjQGz8TOhbL@pryzbyj2023>
 <CAPpHfdvz3S7SoRiaSk9C-Juy2EzHs6NC_c9uUR0i7bymKXkvuQ@mail.gmail.com>
 <ai_c4-v8iLA2kXFV@pryzbyj2023>
 <CAPpHfdvOvaPxMoUp3T6hf4UmAaOhdPCcw71OGUWDjTXvrTZ_JA@mail.gmail.com>
 <CALT9ZEFrDgha=RyOuWru45FTk9Dbj5FF-fTw0NnE8n1FwBb2yg@mail.gmail.com>
 <CAPpHfdvpzvNt=d_Csxe-TCtvF9MRNdeMtfJu3RkmTgBkkQbGUw@mail.gmail.com>
 <CALT9ZEG0YmzH+3M6PixHUNq13pYt+yh8sAgonfaut=g_ij=oZw@mail.gmail.com>
 <CAPpHfdtVp5Xxz59Zse+Gg_oWvZPpwjr+gcVtWq-5pTp0Rsh8gQ@mail.gmail.com>
 <CALT9ZEG39=w6zvDqpKc479WjmeNGFMwdJxi=Ut7z4JUN386URg@mail.gmail.com>
 <CAPpHfdte=WJQnEnEhf8cKZYE1rT-VfQ2mgh=1dCsCCdSYStSow@mail.gmail.com>
 <aj6BPoziSb-F8aJz@pryzbyj2023>
In-Reply-To: <aj6BPoziSb-F8aJz@pryzbyj2023>
From: Pavel Borisov <pashkin.elfe@gmail.com>
Date: Fri, 26 Jun 2026 17:47:06 +0400
Message-ID: 
 <CALT9ZEG8F_oTZEp7vpqJH6Y4hGuQ6jEusETk+=C4XciedS0G1w@mail.gmail.com>
Subject: Re: Add SPLIT PARTITION/MERGE PARTITIONS commands
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: Alexander Korotkov <aekorotkov@gmail.com>,
 Dmitry Koval <d.koval@postgrespro.ru>,
	Alexander Lakhin <exclusion@gmail.com>, pgsql-hackers@lists.postgresql.org,
	Tomas Vondra <tomas.vondra@enterprisedb.com>,
 Alvaro Herrera <alvherre@alvh.no-ip.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
 <https://www.postgresql.org/message-id/CALT9ZEG8F_oTZEp7vpqJH6Y4hGuQ6jEusETk%2B%3DC4XciedS0G1w%40mail.gmail.com>
Precedence: bulk

Hi, Justin!

On Fri, 26 Jun 2026 at 17:40, Justin Pryzby <pryzby@telsasoft.com> wrote:
>
> 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;

Thank you for reporting on this feature!
Yes, I think main motivation for not allowing a partition bounds gaps for
merge was the complication in case a DEFAULT partition exists.
Probably, this could be relaxed when there is no DEFAULT partition.

Regards,
Pavel Borisov
Supabase