On Tue, Aug 06, 2019 at 06:58:44PM -0400, Tom Lane wrote: > Alvaro Herrera <alvhe...@2ndquadrant.com> writes: > > On 2019-Aug-06, Tom Lane wrote: > >> Seems like "it's likely to cause trouble for users" is just going to > >> beg the question "why?". Can we explain the hazard succinctly? > >> Or point to a comment somewhere else that explains it? > > > Right ... the "trouble" is just that if the user later wants to add the > > missing partitions, they'll need to acquire some strong lock (IIRC it's AEL) > > in the partitioned table, so it effectively means an outage. With > > list/range partitioning, there's the slight advantage that you don't > > have to guess all your partitions in advance, or cover data values that > > are required for a very small number of rows. In hash partitioning you > > can't really predict which values are those going to be, and the set of > > missing partitions is perfectly known. > > Hmm. So given the point about it being hard to predict which hash > partitions would receive what values ... under what circumstances > would it be sensible to not create a full set of partitions? Should > we just enforce that there is a full set, somehow?
+1 for requiring that hash partitions not have gaps, ideally by making one call create all the partitions. Best, David. -- David Fetter <david(at)fetter(dot)org> http://fetter.org/ Phone: +1 415 235 3778 Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
