Re: [PATCH] Automatic HASH and LIST partition creation

From: Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>
To: Rahila Syed <rahilasyed90(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Amul Sul <sulamul(at)gmail(dot)com>
Subject: Re: [PATCH] Automatic HASH and LIST partition creation
Date: 2020-10-01 16:02:04
Message-ID: 199124d5-e710-71a6-1836-4653cd668d96@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andy Fan 2020-10-01 16:04:34 Improve choose_custom_plan for initial partition prune case
Previous Message Bharath Rupireddy 2020-10-01 15:46:00 Re: Retry Cached Remote Connections for postgres_fdw in case remote backend gets killed/goes away