Robert Haas wrote: > On Mon, Sep 11, 2017 at 4:17 AM, Ashutosh Bapat > <ashutosh.ba...@enterprisedb.com> wrote: > >> Rebased 0002 against this commit & renamed to 0001, PFA. > > > > Given that we have default partition support now, I am wondering > > whether hash partitioned tables also should have default partitions. > > The way we have structured hash partitioning syntax, there can be > > "holes" in partitions. Default partition would help plug those holes. > > Yeah, I was thinking about that, too. On the one hand, it seems like > it's solving the problem the wrong way: if you've set up hash > partitioning properly, you shouldn't have any holes. On the other > hand, supporting it probably wouldn't cost anything noticeable and > might make things seem more consistent. I'm not sure which way to > jump on this one.
How difficult/tedious/troublesome would be to install the missing partitions if you set hash partitioning with a default partition and only later on notice that some partitions are missing? I think if the answer is that you need to exclusive-lock something for a long time and this causes a disruption in production systems, then it's better not to allow a default partition at all and just force all the hash partitions to be there from the start. On the other hand, if you can get tuples out of the default partition into their intended regular partitions without causing any disruption, then it seems okay to allow default partitions in hash partitioning setups. (I, like many others, was unable to follow the default partition stuff as closely as I would have liked.) -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
