Re: no default hash partition

Alvaro Herrera <alvherre(at)2ndquadrant(dot)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?

regards, tom lane