On Tue, Aug 06, 2019 at 06:58:44PM -0400, Tom Lane wrote:
> Alvaro Herrera <alvherre@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
