public inbox for [email protected]
help / color / mirror / Atom feedFrom: Pavel Borisov <[email protected]>
To: Alexander Korotkov <[email protected]>
Cc: Dmitry Koval <[email protected]>
Cc: Justin Pryzby <[email protected]>
Cc: [email protected]
Subject: Re: Add SPLIT PARTITION/MERGE PARTITIONS commands
Date: Tue, 30 Jun 2026 15:25:31 +0400
Message-ID: <CALT9ZEEuOmeJFNUviG4F+ExsVzreBV6=GPRWh-BX0rD4ejPtNA@mail.gmail.com> (raw)
In-Reply-To: <CAPpHfdvwtUvVyE7cvSsvEB_1gAs8XM0mX_CSRooE8sXoO82DtA@mail.gmail.com>
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>
<CALT9ZEG8F_oTZEp7vpqJH6Y4hGuQ6jEusETk+=C4XciedS0G1w@mail.gmail.com>
<[email protected]>
<CAPpHfdsao-VXZYN8-vRm543EFUE7=4tq+hcTh5iEc6ikqWq_cQ@mail.gmail.com>
<CAPpHfdvwtUvVyE7cvSsvEB_1gAs8XM0mX_CSRooE8sXoO82DtA@mail.gmail.com>
Hi, Alexander!
On Tue, 30 Jun 2026 at 15:07, Alexander Korotkov <[email protected]> wrote:
>
> On Fri, Jun 26, 2026 at 10:50 PM Alexander Korotkov
> <[email protected]> wrote:
> > On Fri, Jun 26, 2026 at 6:20 PM Dmitry Koval <[email protected]> wrote:
> > > If we exclude case with DEFAULT partition, MERGE PARTITIONS command was
> > > intended to be used when an incorrect table partitioning was chosen.
> > > For example, a table was initially partitioned by month, but later we
> > > needed to change table partitioning by quarter. In this case, MERGE
> > > PARTITIONS command should merge several adjacent partitions into one.
> > > Current checks are made for this case.
> > >
> > > >- 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;
> > >
> > > It's probably possible to do this. But in this case, the command will
> > > not exactly be "MERGE PARTITIONS" ("MERGE PARTITIONS & EXPAND"?).
> >
> > +1,
> > We can implement a support for this for 20. For 19, I propose to
> > state the restriction more explicit in the docs. See the attached
> > patch.
>
> I'm going to push the docs patch if no objections.
I looked at the doc patch. IMO "in order to be merged" is redundant.
I'd propose following:
"For range-partitioned tables, the ranges of merged partitions must be
adjacent. This applies even if the partitioned table has no default
partition."
Regards,
Pavel Borisov
Supabase
view thread (174+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Add SPLIT PARTITION/MERGE PARTITIONS commands
In-Reply-To: <CALT9ZEEuOmeJFNUviG4F+ExsVzreBV6=GPRWh-BX0rD4ejPtNA@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox