On Wed, Jul 14, 2021 at 7:28 AM Pavel Borisov <pashkin.e...@gmail.com> wrote: > What do you think will the described approach lead to a useful patch? Should > it be done as a whole or it's possible to commit it in smaller steps? (E.g. > first part without AUTOMATIC capability, then add AUTOMATIC capability. Or > with some other order of features implementation)
I would suggest that you consider on-the-fly partition creation to be a completely separate feature from initial partition creation as part of CREATE TABLE. I think you can have either without the other, and I think the latter is a lot easier than the former. I doubt that on-the-fly partition creation makes any sense at all for hash partitions; there seems to be no reason not to pre-create all the partitions. It's pretty straightforward to see how it should work for LIST, but RANGE needs an interval or something to be stored in the system catalogs so you can figure out where to put the boundaries, and somehow you've got to identify a + operator for the relevant data type. Tom Lane probably won't be thrilled if you suggest looking it up based on the operator NAME. The bigger issue IMHO with on-the-fly partition creation is avoiding deadlocks in the presence of current inserters; I submit that without at least some kind of attempt to avoid deadlocks and spurious errors there, it's not really a usable scheme, and that seems hard. On the other hand, modulo syntax details, creating partitions at CREATE TABLE time seems relatively simple and, especially in the case of hash partitioning, useful. -- Robert Haas EDB: http://www.enterprisedb.com
