Re: [PATCH] Automatic HASH and LIST partition creation

Anastasia Lubennikova <a.lubennikova@postgrespro.ru>

From: Anastasia Lubennikova <a.lubennikova@postgrespro.ru>
To: Rahila Syed <rahilasyed90@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, Pavel Borisov <pashkin.elfe@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Fabien COELHO <coelho@cri.ensmp.fr>, Justin Pryzby <pryzby@telsasoft.com>, Robert Haas <robertmhaas@gmail.com>, Amul Sul <sulamul@gmail.com>
Date: 2020-10-01T16:02:04Z
Lists: pgsql-hackers
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

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Remove complaints about COLLATE clauses in partition bound values.