On 2019-Aug-06, Tom Lane wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > Given the discussion starting at
> > https://postgr.es/m/CAFjFpRdBiQjZm8sG9+s0x8Re-afHds6MFLgGuw0wVUNLGrVOQg@mail.gmail.com
> > we don't have default-partition support with the hash partitioning
> > scheme. That seems a reasonable outcome, but I think we should have a
> > comment about it (I had to search the reason for this restriction in the
> > hash-partitioning patch set). How about the attached? Does anyone see
> > a reason to make this more verbose, and if so to what?
>
> 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.
Not enlightened enough ATM for a succint enough explanation, but I'll
take suggestions.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services