Re: no default hash partition

From: Amit Langote <amitlangote09(at)gmail(dot)com>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: no default hash partition
Date: 2019-08-07 05:51:45
Message-ID: CA+HiwqFVmp1HF6KT_jpch9kvCrydivDdW-gP1XhUOUznG_by-Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Horiguchi-san,

On Wed, Aug 7, 2019 at 1:59 PM Kyotaro Horiguchi
<horikyota(dot)ntt(at)gmail(dot)com> wrote:
> At Tue, 6 Aug 2019 23:26:19 -0400, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> > On Tue, Aug 6, 2019 at 6:58 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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?

Thanks,
Amit

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2019-08-07 06:01:58 Re: proposal: type info support functions for functions that use "any" type
Previous Message Pavel Stehule 2019-08-07 05:32:04 is necessary to recheck cached data in fn_extra?