Re: no default hash partition

Greetings,

* Amit Langote (amitlangote09@gmail.com) wrote:
> On Wed, Aug 7, 2019 at 1:59 PM Kyotaro Horiguchi
> <horikyota.ntt@gmail.com> wrote:
> > At Tue, 6 Aug 2019 23:26:19 -0400, Robert Haas <robertmhaas@gmail.com> wrote:
> > > On Tue, Aug 6, 2019 at 6:58 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > > I think, as Amit says, that having an automatic partition creation
> > > feature for hash partitions (and maybe other kinds, but certainly for
> > > hash) would be a useful thing to add to the system. I also think that
> > > it might be useful to add some commands to automate partition
> > > splitting (and maybe combining) although I think there's some design
> > > work to be done there to figure out exactly what we should build.  I
> > > don't think it's ever useful to have a hash-partitioned table with an
> > > incomplete set of partitions long term, but it makes things simpler to
> > > allow that temporarily, for example during dump restoration.
> > > Therefore, I see no reason why we would want to go to the trouble of
> > > allowing hash-partitioned tables to have default partitions; it would
> > > just encourage people to do things that don't really make any sense.
> >
> > +1.
> >
> > By the way, couldn't we offer a means to check for gaps in a hash
> > partition? For example, the output of current \d+ <parent>
> > contains the Partitoins section that shows a list of
> > partitions. I think that we can show all gaps there.
> >
> > =# \d+ p
> >                                Partitioned table "public.p"
> > ...
> > Partition key: HASH (a)
> > Partitions: c1 FOR VALUES WITH (modulus 4, remainder 0),
> >             c3 FOR VALUES WITH (modulus 4, remainder 3),
> >             GAP (modulus 4, remainder 1),
> >             GAP (modulus 4, remainder 2)
> >
> > Or
> >
> > Partitions: c1 FOR VALUES WITH (modulus 4, remainder 0),
> >             c3 FOR VALUES WITH (modulus 4, remainder 3),
> > Gaps: (modulus 4, remainder 1), (modulus 4, remainder 2)
>
> I imagine showing this output would require some non-trivial code on
> the client side (?) to figure out the gaps.  If our intention in the
> long run is to make sure that such gaps only ever appear temporarily,
> that is, when running a command to increase the number of hash
> partitions (as detailed in Robert's email), then a user would never
> see those gaps.  So, maybe writing such code wouldn't be worthwhile in
> the long run?

I tend to agree that it might not be useful to have this code,
particularly not on the client side, but we've dealt with the issue of
"the client would need non-trivial code for this" in the past by having
a server-side function for the client to call (eg: pg_get_expr(),
pg_get_ruledef()).  If we really think this would be valuable to show
and we don't want the client to have to have a bunch of code for it,
doing something similar here could address that.

One thing I've wished for is a function that would give me a range type
back for a partition (would be neat to be able to use a range type to
specify a partition's range when creating it too).

Thanks,

Stephen