public inbox for [email protected]  

help / color / mirror / Atom feed

From: Anastasia Lubennikova <[email protected]>
To: Rahila Syed <[email protected]>
Cc: Michael Paquier <[email protected]>
Cc: Pavel Borisov <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Cc: Fabien COELHO <[email protected]>
Cc: Justin Pryzby <[email protected]>
Cc: Robert Haas <[email protected]>
Cc: Amul Sul <[email protected]>
Subject: Re: [PATCH] Automatic HASH and LIST partition creation
Date: Thu, 1 Oct 2020 19:02:04 +0300
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAH2L28v_fmXvDF+UzMDCObgd7nuqSU=HAJPfw7w4TMx5HGv5ig@mail.gmail.com>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<CALT9ZEECZacCRuSthkq5ivOysL5E--v6vr9=0CFouSjEKpbOow@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<CAH2L28v_fmXvDF+UzMDCObgd7nuqSU=HAJPfw7w4TMx5HGv5ig@mail.gmail.com>

On 30.09.2020 22:58, Rahila Syed wrote:
> Hi Anastasia,
>
> I tested the syntax with some basic commands and it works fine, 
> regression tests also pass.
>
Thank you for your review.
> Couple of comments:
> 1. The syntax used omits the { IMMEDIATE | DEFERRED} keywords 
> suggested in
> the earlier discussions. I think it is intuitive to include IMMEDIATE 
> with the current implementation
> so that the syntax can be extended with a  DEFERRED clause in future 
> for dynamic partitions.
>
>       CREATE TABLE tbl_lst (i int) PARTITION BY LIST (i)
>      CONFIGURATION (values in (1, 2), (3, 4) DEFAULT PARTITION
>     tbl_default);
>
After some consideration, I decided that we don't actually need to 
introduce IMMEDIATE | DEFERRED keyword. For hash and list partitions it 
will always be immediate, as the number of partitions cannot change 
after we initially set it. For range partitions, on the contrary, it 
doesn't make much sense to make partitions immediately, because in many 
use-cases one bound will be open.

> 2. One suggestion for generation of partition names is to append a 
> unique id to
> avoid conflicts.

Can you please give an example of such a conflict? I agree that current 
naming scheme is far from perfect, but I think that 'tablename'_partnum 
provides unique name for each partition.

>
> 3. Probably, here you mean to write list and hash instead of range and 
> list as
> per the current state.
>
>          <para>
>          Range and list partitioning also support automatic creation
>     of partitions
>           with an optional <literal>CONFIGURATION</literal> clause.
>         </para>
>
> 4. Typo in default_part_name
>
>     +VALUES IN ( <replaceable
>     class="parameter">partition_bound_expr</replaceable> [, ...] ), [(
>     <replaceable class="parameter">partition_bound_expr</replaceable>
>     [, ...] )] [, ...] [DEFAULT PARTITION <replaceable
>     class="parameter">defailt_part_name</replaceable>]
>     +MODULUS <replaceable class="parameter">numeric_literal</replaceable>
>
>
Yes, you're right. I will fix these typos in next version of the patch.
>
> Thank you,
> Rahila Syed


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

view thread (38+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: [PATCH] Automatic HASH and LIST partition creation
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox