Re: [PATCH] Automatic HASH and LIST partition creation
Stéphane Tachoires <stephane.tachoires@gmail.com>
From: Stéphane Tachoires <stephane.tachoires@gmail.com>
To: Daniel Gustafsson <daniel@yesql.se>
Cc: Anastasia Lubennikova <a.lubennikova@postgrespro.ru>,
Robert Haas <robertmhaas@gmail.com>, Justin Pryzby <pryzby@telsasoft.com>, Pavel Borisov <pashkin.elfe@gmail.com>, Thomas Munro <thomas.munro@gmail.com>, Rahila Syed <rahilasyed90@gmail.com>, Michael Paquier <michael@paquier.xyz>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
Fabien COELHO <coelho@cri.ensmp.fr>, Amul Sul <sulamul@gmail.com>
Date: 2023-07-17T14:26:14Z
Lists: pgsql-hackers
Attachments
- v7-0001-This-is-a-simple-rebase-on-most-recent-17dev.patch (text/x-patch) patch v7-0001
Hi, I found that thread (and the patch), but it seems to be pretty dead. Patch didn't apply, due to gen_node_support.pl Can I hope for a rebirth ? I've made a rebased patch,in case of no response... It's just the patch from https://www.postgresql.org/message-id/CALT9ZEG9oKz9-dv9YYZaeeXNpZp0+teLFSz7QST28AcmERVpiw@mail.gmail.com rebased on 17dev Perhaps it's too early for a commit ; automatic range partitioning is still missing and, according to https://wiki.postgresql.org/wiki/Declarative_partitioning_improvements, syntax is arguable. If 'USING' it out of option (already a keyword for CREATE TABLE) and 'CONFIGURATION()' is not what we want, we should reach for a final decision first. I suggest OVER that is a keyword but unused in CREATE TABLE (nor ALTER TABLE). Whatever... For RANGE partitioning I think of four syntaxes (inspired by pg_partman) PARTITION BY RANGE(stamp) CONFIGURATION (SPAN interval CENTER datetime BACK integer AHEAD integer [DEFAULT [PARTITION] [defname]]) PARTITION BY RANGE(stamp) CONFIGURATION (SPAN interval START firstfrombound END lasttobound [DEFAULT [PARTITION] [defname]]) PARTITION BY RANGE(region_id) CONFIGURATION (STEP integer START integer END integer [DEFAULT [PARTITION] [defname]]) PARTITION BY RANGE(name) CONFIGURATION (BOUNDS (boundlist) [START firstfrombound] [END lasttobound] [DEFAULT [PARTITION] [defname]]) Last one should solve the addition operator problem with non numeric non timedate range. Plus, it allows non uniform range (thinking about an "encyclopedia volume" partitioning, you know 'A', 'B-CL', 'CL-D'...) CREATE table (LIKE other INCLUDING PARTITIONS) should create 'table' partitioned the same as 'other' and CREATE table (LIKE other INCLUDING PARTITIONS) PARTITION BY partspec CONFIGURATION(), should create 'table' partitioned by partspec and sub partitioned as 'other'. Then CREATE could accept multiple PARTITION BY CONFIGURATION(). For ALTER TABLE (and automatic maintenance) to be usable, we will need SPLIT and MERGE CONCURRENTLY (pg_pathman ?) enhanced by CREATE TABLE LIKE to handle subpartitioning. But that's another story. Stéphane. Le jeu. 2 déc. 2021 à 12:20, Daniel Gustafsson <daniel@yesql.se> a écrit : > This thread has stalled since July with review comments unanswered, I'm > marking > the patch Returned with Feedback. Please feel free to resubmit when/if a > new > patch is available. > > -- > Daniel Gustafsson https://vmware.com/ > > > > -- "Où se posaient les hirondelles avant l'invention du téléphone ?" -- Grégoire Lacroix
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Remove complaints about COLLATE clauses in partition bound values.
- 2dfa3fea88bc 14.0 cited