Re: Proposal: Automatic partition creation

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Proposal: Automatic partition creation
Date: 2020-07-08 04:53:52
Message-ID: alpine.DEB.2.22.394.2007080631500.261743@pseudo
Views: Raw Message | Whole Thread | Download mbox | Resend email
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
> 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:


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]

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


In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2020-07-08 04:57:21 Use incremental sort paths for window functions
Previous Message Fabien COELHO 2020-07-08 04:42:14 Re: some more pg_dump refactoring