From: | Rahila Syed <rahilasyed90(at)gmail(dot)com> |
---|---|
To: | Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru> |
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-05 06:36:49 |
Message-ID: | CAH2L28vRKPw+uf3Voiy6zy5QUghTPueErNTz_xgpkxEKnmfL1A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
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.
>
>
As per discussions on this thread:
https://www.postgresql.org/message-id/flat/alpine.DEB.2.21.1907150711080.22273%40lancre
DEFERRED clause refers to creating partitions on the fly, while the data is
being inserted.
The number of partitions and partition bounds can be the same as specified
initially
during partitioned table creation, but the actual creation of
partitions can be deferred.
This seems like a potential extension to statically created partitions even
in the case of
hash and list partitions, as it won't involve moving any existing data.
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.
>
>
> Sorry for not being clear earlier, I mean the partition name
'tablename_partnum' can conflict with any existing table name.
As per current impemetation, if I do the following it results in the table
name conflict.
postgres=# create table tbl_test_5_1(i int);
CREATE TABLE
postgres=# CREATE TABLE tbl_test_5 (i int) PARTITION BY LIST((tbl_test_5))
CONFIGURATION (values in
('(1)'::tbl_test_5), ('(3)'::tbl_test_5) default partition tbl_default_5);
ERROR: relation "tbl_test_5_1" already exists
Thank you,
Rahila Syed
>
From | Date | Subject | |
---|---|---|---|
Next Message | Dilip Kumar | 2020-10-05 07:48:14 | Re: [HACKERS] Custom compression methods |
Previous Message | Etsuro Fujita | 2020-10-05 06:35:36 | Re: Asynchronous Append on postgres_fdw nodes. |