Re: Add SPLIT PARTITION/MERGE PARTITIONS commands

Alexander Korotkov <aekorotkov@gmail.com>

From: Alexander Korotkov <aekorotkov@gmail.com>
To: Pavel Borisov <pashkin.elfe@gmail.com>
Cc: Dmitry Koval <d.koval@postgrespro.ru>, Noah Misch <noah@leadboat.com>, pgsql-hackers@lists.postgresql.org
Date: 2024-08-21T12:40:44Z
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.

Attachments

On Wed, Aug 21, 2024 at 3:06 PM Pavel Borisov <pashkin.elfe@gmail.com> wrote:
> On Wed, 21 Aug 2024 at 15:55, Alexander Korotkov <aekorotkov@gmail.com> wrote:
>>
>> Hi, Pavel!
>>
>> On Wed, Aug 21, 2024 at 1:48 PM Pavel Borisov <pashkin.elfe@gmail.com> wrote:
>> > On Mon, 19 Aug 2024 at 02:24, Alexander Korotkov <aekorotkov@gmail.com> wrote:
>> >>
>> >> On Sat, Aug 10, 2024 at 6:57 PM Dmitry Koval <d.koval@postgrespro.ru> wrote:
>> >> > > Probably
>> >> > > QueryCompletion struct fits this purpose best from the existing
>> >> > > parameters.  Attached draft patch implements returning oid of newly
>> >> > > created relation as part of QueryCompletion.  Thoughts?
>> >> >
>> >> > I agree, returning the oid of the newly created relation is the best way
>> >> > to solve the problem.
>> >> > (Excuse me, I won't have access to a laptop for the next week - and
>> >> > won't be able to look at the source code).
>> >>
>> >> Thank you for your feedback.  Although, I decided QueryCompletion is
>> >> not a good place for this new field.  It looks more appropriate to
>> >> place it to TableLikeClause, which already contains one relation oid
>> >> inside.  The revised patch is attached.
>> >
>> >
>> > I've looked at the patch v2. Remembering the OID of a relation newly created with LIKE in TableLikeClause seems good to me.
>> > Check-world passes sucessfully.
>>
>> Thank you.
>>
>> > Shouldn't we also modify the TableLikeClause node in gram.y accordingly?
>>
>> On the one hand, makeNode() uses palloc0() and initializes all fields
>> with zero anyway.  On the other hand, there is already assignment of
>> relationOid.  So, yes I'll add assignment of newRelationOid for the
>> sake of uniformity.
>>
>> > For the comments:
>> > Put the Oid  -> Store the OID
>>
>> > so caller might use it -> for the caller to use it.
>>
>> Accepted.
>>
>> > (Maybe also caller -> table create function)
>>
>> I'll prefer to leave it "caller" as more generic term, which could
>> also fit potential future usages.
>>
>> The revised patch is attached.  I'm going to push it if no objections.
>
> Looked at v3
> All good except the patch has "Oid" and "OID" in two comments. I suppose "OID" is preferred elsewhere in the PG comments.

Correct, the same file contains "OID" multiple times.  Revised version
is attached.

------
Regards,
Alexander Korotkov
Supabase