Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jv5kg-0001uA-G4 for pgsql-hackers@arkaria.postgresql.org; Mon, 13 Jul 2020 21:12:43 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jv5k6-0001Y2-PH for pgsql-hackers@arkaria.postgresql.org; Mon, 13 Jul 2020 21:12:06 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jv5k6-0001Xv-GC for pgsql-hackers@lists.postgresql.org; Mon, 13 Jul 2020 21:12:06 +0000 Received: from mail.postgrespro.ru ([93.174.131.139]) by makus.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jv5k2-0006Za-UV for pgsql-hackers@lists.postgresql.org; Mon, 13 Jul 2020 21:12:05 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.postgrespro.ru (Postfix) with ESMTP id A320221C76ED; Tue, 14 Jul 2020 00:12:00 +0300 (MSK) X-Virus-Scanned: Debian amavisd-new at postgrespro.ru X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-99 required=4 WHITELISTED tests=[] autolearn=unavailable Received: from [192.168.0.18] (broadband-46-242-11-178.ip.moscow.rt.ru [46.242.11.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail.postgrespro.ru (Postfix) with ESMTPSA id 6712321C76EB; Tue, 14 Jul 2020 00:12:00 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mail; t=1594674720; bh=4R9e23biz16aVh2NFJCvnI0AzfR2W2Qx3903HDQf/c8=; h=Subject:References:From:To:Cc:Date:In-Reply-To; b=b+iy2GdsWwURnw6QPXEOzCLnE6pyTsbSX/Vg1SxMMxniB00zYkq+GY5P1BOSgFRra 3y19KtS6cudf/+Xt7U0DFZjKORlX+ZjgmCmfGq9hIudqF3Qfj0EyUMYwZOQv3DaaVP O9uJ/84Whx4hseKCRwDu6PDfvc9bFbQhuRbET6Ec= Subject: Re: Proposal: Automatic partition creation References: <7fec3abb-c663-c0d2-8452-a46141be6d4a@postgrespro.ru> From: Anastasia Lubennikova To: PostgreSQL Hackers Cc: Fabien COELHO , Justin Pryzby , Robert Haas , Amul Sul Message-ID: <7c4013db-a628-c8bd-ce54-064389109e0f@postgrespro.ru> Date: Tue, 14 Jul 2020 00:11:56 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <7fec3abb-c663-c0d2-8452-a46141be6d4a@postgrespro.ru> Content-Type: multipart/alternative; boundary="------------91C44D38F3400B8633F944F3" Content-Language: en-US List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk This is a multi-part message in MIME format. --------------91C44D38F3400B8633F944F3 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 06.07.2020 13:45, Anastasia Lubennikova wrote: > The previous discussion of automatic partition creation [1] has > addressed static and dynamic creation of partitions and ended up with > several syntax proposals. > In this thread, I want to continue this work. > > ... > [1] > https://www.postgresql.org/message-id/flat/alpine.DEB.2.21.1907150711080.22273%40lancre Syntax proposal v2, that takes into account received feedback. I compared the syntax of other databases. You can find an overview here [1]. It seems that there is no industry standard, so every DBMS has its own implementation. I decided to rely on a Greenplum syntax, as the most similar to the original PostgreSQL syntax. New proposal is: CREATE TABLE numbers(int number) PARTITION BY partition_method (list_of_columns) USING (partition_desc) where partition_desc is: MODULUS n | VALUES IN (value_list), [DEFAULT PARTITION part_name] | START ([datatype] 'start_value') END ([datatype] 'end_value') EVERY (partition_step), [DEFAULT PARTITION part_name] where partition_step is: [datatype] [number | INTERVAL] 'interval_value' example: CREATE TABLE years(int year) PARTITION BY RANGE (year) USING (START (2006) END (2016) EVERY (1), DEFAULT PARTITION other_years); It is less wordy than the previous version. It uses a free keyword option style. It covers static partitioning for all methods, default partition for list and range methods, and can be extended to implement dynamic partitioning for range partitions. [1] https://wiki.postgresql.org/wiki/Declarative_partitioning_improvements#Other_DBMS [2] https://wiki.postgresql.org/wiki/Declarative_partitioning_improvements#Proposal_.28is_subject_to_change.29 -- Anastasia Lubennikova Postgres Professional: http://www.postgrespro.com The Russian Postgres Company --------------91C44D38F3400B8633F944F3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 06.07.2020 13:45, Anastasia Lubennikova wrote:
The previous discussion of automatic partition creation [1] has addressed static and dynamic creation of partitions and ended up with several syntax proposals.
In this thread, I want to continue this work.

...
[1] https://www.postgresql.org/message-id/flat/alpine.DEB.2.21.1907150711080.22273%40lancre

Syntax proposal v2, that takes into account received feedback.

I compared the syntax of other databases. You can find an overview here [1]. It
seems that there is no industry standard, so every DBMS has its own
implementation. I decided to rely on a Greenplum syntax, as the most similar to
the original PostgreSQL syntax.

New proposal is:

CREATE TABLE numbers(int number)
PARTITION BY partition_method (list_of_columns)
USING (partition_desc)

where partition_desc is:

MODULUS n
| VALUES IN (value_list), [DEFAULT PARTITION part_name]
| START ([datatype] 'start_value')
  END ([datatype] 'end_value')
  EVERY (partition_step), [DEFAULT PARTITION part_name]

where partition_step is:
[datatype] [number | INTERVAL] 'interval_value'
 
example:

CREATE TABLE years(int year)
PARTITION BY RANGE (year)
USING
(START (2006) END (2016) EVERY (1),
DEFAULT PARTITION other_years);

It is less wordy than the previous version. It uses a free keyword option
style. It covers static partitioning for all methods, default partition for
list and range methods, and can be extended to implement dynamic partitioning
for range partitions.

[1] https://wiki.postgresql.org/wiki/Declarative_partitioning_improvements#Other_DBMS
[2] https://wiki.postgresql.org/wiki/Declarative_partitioning_improvements#Proposal_.28is_subject_to_change.29

-- 
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--------------91C44D38F3400B8633F944F3--