Re: Proposal: Automatic partition creation

Fabien COELHO <coelho@cri.ensmp.fr>

From: Fabien COELHO <coelho@cri.ensmp.fr>
To: Anastasia Lubennikova <a.lubennikova@postgrespro.ru>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-07-08T04:53:52Z
Lists: pgsql-hackers
Hello Anastasia,

My 0.02 €:

> The patch implements following syntax:
>
> CREATE TABLE ... PARTITION BY partition_method (list_of_columns)
> partition_auto_create_clause
>
> where partition_auto_create_clause is
>
> CONFIGURATION [IMMEDIATE| DEFERRED] USING partition_bound_spec
>
> and partition_bound_spec is:
>
> MODULUS integer | VALUES IN (expr [,...]) [, ....] |  INTERVAL range_step 
> FROM range_start TO range_end

ISTM That we should avoid new specific syntaxes when possible, and prefer 
free keyword option style, like it is being discussed for some other 
commands, because it reduces the impact on the parser.

That would suggest a more versatile partition_bound_spec which could look 
like  (<keyword> <constant-or-maybe-even-expr>[, …]):

For modulus, looks easy:

   (MODULUS 8)

For interval, maybe something like:

   (STEP ..., FROM/START ..., TO/END ...)

The key point is that for dynamic partitioning there would be no need for 
boundaries, so that it could just set a point and an interval

   (START/INIT/FROM??? ..., STEP ...)

For lists of values, probably it would make little sense to have dynamic 
partitioning? Or maybe yes, if we could partition on a column 
value/expression?! eg "MOD(id, 8)"??

What about pg_dump? Should it be able to regenerate the initial create?

> [4] https://wiki.postgresql.org/wiki/Declarative_partitioning_improvements

Good point, a wiki is better than a thread for that type of things. I'll 
look at this page.

-- 
Fabien.

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.