Re: no default hash partition

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