Re: no default hash partition - Mailing list pgsql-hackers

From Tom Lane
Subject Re: no default hash partition
Date
Msg-id 16738.1565132324@sss.pgh.pa.us
Whole thread Raw
In response to Re: no default hash partition  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: no default hash partition
Re: no default hash partition
Re: no default hash partition
List pgsql-hackers
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?

            regards, tom lane



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: no default hash partition
Next
From: Stephen Frost
Date:
Subject: Re: no default hash partition