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

From Amit Langote
Subject Re: no default hash partition
Date
Msg-id CA+HiwqF=RKegkjMxN57T9r44U_ehNksPAgrc9dhu01s8NWJ9FQ@mail.gmail.com
Whole thread Raw
In response to no default hash partition  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: no default hash partition  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Re: no default hash partition  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
Hi Alvaro,

On Wed, Aug 7, 2019 at 7:27 AM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
>
> 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).

That hash-partitioned tables can't have default partition is mentioned
in the CREATE TABLE page:

"If DEFAULT is specified, the table will be created as a default
partition of the parent table. The parent can either be a list or
range partitioned table. A partition key value not fitting into any
other partition of the given parent will be routed to the default
partition. There can be only one default partition for a given parent
table."

>  How about the attached?  Does anyone see
> a reason to make this more verbose, and if so to what?

If the outcome of this discussion is that we expand our internal
documentation of why there's no default hash partition, then should we
also expand the user documentation somehow?

Thanks,
Amit



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: More issues with pg_verify_checksums and checksum verificationin base backups
Next
From: Etsuro Fujita
Date:
Subject: Re: partition routing layering in nodeModifyTable.c