Horton

Re: Add SPLIT PARTITION/MERGE PARTITIONS commands

Alexander Korotkov <aekorotkov@gmail.com>

View thread
From: Alexander Korotkov <aekorotkov@gmail.com>
To: Dmitry Koval <d.koval@postgrespro.ru>
Cc: jian he <jian.universality@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2025-07-29T09:38:22Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Adjust errcode in checkPartition()

  2. Fix usage of palloc() in MERGE/SPLIT PARTITION(s) code

  3. Implement ALTER TABLE ... SPLIT PARTITION ... command

  4. Implement ALTER TABLE ... MERGE PARTITIONS ... command

  5. Calculate agglevelsup correctly when Aggref contains a CTE.

  6. Use PqMsg_* macros in applyparallelworker.c.

  7. Restrict psql meta-commands in plain-text dumps.

  8. Ensure we have a snapshot when updating various system catalogs.

  9. Use specific collation where needed in new test

  10. Expand virtual generated columns in the planner

  11. Virtual generated columns

  12. Define PG_LOGICAL_DIR for path pg_logical/ in data folder

  13. Revert support for ALTER TABLE ... MERGE/SPLIT PARTITION(S) commands

  14. Avoid repeated table name lookups in createPartitionTable()

  15. Provide deterministic order for catalog queries in partition_split.sql

  16. Don't copy extended statistics during MERGE/SPLIT partition operations

  17. Fix the name collision detection in MERGE/SPLIT partition operations

  18. Fix regression tests conflict in 3ca43dbbb6

  19. Add permission check for MERGE/SPLIT partition operations

  20. Fix one more portability shortcoming in new test_pg_dump test.

  21. Inherit parent's AM for partition MERGE/SPLIT operations

  22. Add tab completion for partition MERGE/SPLIT operations

  23. Rename tables in tests of partition MERGE/SPLIT operations

  24. Make new partitions with parent's persistence during MERGE/SPLIT

  25. Document the way partition MERGE/SPLIT operations create new partitions

  26. Change the way ATExecMergePartitions() handles the name collision

  27. Grammar fixes for split/merge partitions code

  28. Checks for ALTER TABLE ... SPLIT/MERGE PARTITIONS ... commands

  29. Fix some grammer errors from error messages and codes comments

  30. Support TZ and OF format codes in to_timestamp().

  31. Support identity columns in partitioned tables

  32. Fix indentation in twophase.c

  33. Fix corner-case planner failure for MERGE.

  34. Doc: fix documentation example for bytea hex output format.

  35. Avoid repeated name lookups during table and index DDL.

Hi, Dmitry!

I went through the patches. Both of them applied with a small conflict in
the parallel_schedule, which is easy to resolve.

+               ExecClearTuple(insertslot);
+
+               memcpy(insertslot->tts_values, srcslot->tts_values,
+                      sizeof(Datum) * srcslot->tts_nvalid);
+               memcpy(insertslot->tts_isnull, srcslot->tts_isnull,
+                      sizeof(bool) * srcslot->tts_nvalid);
+
+               ExecStoreVirtualTuple(insertslot);

Similar fragments are present in SplitPartitionMoveRows()
and MergePartitionsMoveRows().  Do you think we could use ExecCopySlot()
(or similar) instead?

The presence of the same name in the split partition list is checked with
equal() (similar concern was already raised about the merge case [1]).  If
one of the names is schema-qualified, the error message is different.
Could we make them the same?

# alter table part_test split partition part_test_1_2 into (partition
part_test_1 for values in (1), partition part_test_1 for values in (2));
ERROR:  name "part_test_1" is already used
LINE 1: ...artition part_test_1 for values in (1), partition part_test_...
                                                             ^
Time: 1.194 ms
# alter table part_test split partition part_test_1_2 into (partition
part_test_1 for values in (1), partition public.part_test_1 for values in
(2));
ERROR:  relation "part_test_1" already exists
Time: 6.187 ms

+       /* Search partition for current slot srcslot. */
+       foreach(listptr, partContexts)
+       {
+           pc = (SplitPartitionContext *) lfirst(listptr);
+
+           /* skip DEFAULT partition */
+           if (pc->partqualstate && ExecCheck(pc->partqualstate, econtext))
+           {
+               found = true;
+               break;
+           }
+       }

I see we're searching for a partition to place each row using the
sequential application of partition constraints.  I concerned if this could
be exhausting when the number of new partitions is large.  Could we use
something like binary search here?

New split/drop commands do the full reorganization of the involved
partitions.  As Robert previously stated [2], there are other possible
strategies.  While they are hard to implement, I don't think we need them
in the initial version.  But I think it's worth mentioning in the docs that
we're completely rewriting the involved partitions.  And this is not
recommended to use for merging very big partitions with small ones, and
splitting a small fraction of rows out of a very big partition.

Both patches could use pgindent run.

Links
1.
https://www.postgresql.org/message-id/CACJufxHHnJm6Jb2YQpuRU1RX__tO%3DJJNJ5%3DEUMuzif_KNxGd9A%40mail.gmail.com
2.
https://www.postgresql.org/message-id/CA%2BTgmoY0%3DbT_xBP8csR%3DMFE%3DFxGE2n2-me2-31jBOgEcLvW7ug%40mail.gmail.com

------
Regards,
Alexander Korotkov
Supabase