| From: | Dmitry Koval <d(dot)koval(at)postgrespro(dot)ru> |
|---|---|
| To: | Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Add SPLIT PARTITION/MERGE PARTITIONS commands |
| Date: | 2026-06-26 15:20:18 |
| Message-ID: | 232439a3-af7a-4a13-82ae-33da5520d4bf@postgrespro.ru |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi!
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"?).
--
With best regards,
Dmitry Koval
Postgres Professional: http://postgrespro.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Antonin Houska | 2026-06-26 15:23:53 | Re: CLUSTER progress: wrong index_rebuild_count for tables with TOAST |
| Previous Message | wenhui qiu | 2026-06-26 14:54:44 | Re: Report oldest xmin source when autovacuum cannot remove tuples |