Re: pgsql: Allow UNIQUE indexes on partitioned tables

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pgsql: Allow UNIQUE indexes on partitioned tables
Date: 2018-02-20 15:36:47
Message-ID: 20180220153647.blzfw7u47ykjkdsc@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Many thanks for reading through it!

David G. Johnston wrote:
> I found the following change to be confusing.
[...]
> I was expecting the doc for ADD CONSTRAINT USING INDEX to note the
> limitation explicitly - in lieu of the above paragraph.

Agreed. I moved the note to ADD CONSTRAINT and added a different on to
ADD CONSTRAINT USING INDEX.

> Also, I cannot reason out what the following limitation means:
>
> /doc/src/sgml/ref/create_table.sgml
> + If any partitions are in turn partitioned, all columns of each
> partition
> + key are considered at each level below the <literal>UNIQUE</literal>
> + constraint.

I can see that being unclear. I tried to be very concise, to avoid
spending too many words on what is mostly a fringe feature; but that
probably didn't work very well. Wording suggestions welcome. What this
means is that if you create a partition that is partitioned on a column
different from its parent, then a primary key that covers the whole
hierarchy (i.e. you're not just adding a PK to the partitioned
partition) must include all partition columns, not just the upper one.

Example:

create table t (a int, b int) partition by range (a);
create table t_1 partition of t for values from (0) to (1000) partition by range (b);

then you may create a unique or PK constraint on t only if you include
both columns (a,b). You may not create a PK on t (a), which is a bit
surprising since (b) is not part of the partition key of t directly,
only of t_1.

Of course, if you create a unique constraint on t_1 (i.e. it doesn't
cover all of t) then you may use (b) alone -- that's what "each level
below the UNIQUE constraint" supposed to convey.

I have trouble coming up with a real-world example where you would run
into this limitation in practice.

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2018-02-20 16:23:52 pgsql: Fix pg_dump's logic for eliding sequence limits that match the d
Previous Message Alvaro Herrera 2018-02-20 15:16:56 pgsql: Adjust ALTER TABLE docs on partitioned constraints

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabrízio de Royes Mello 2018-02-20 15:38:56 Re: [PATCH] Add support for ON UPDATE/DELETE actions on ALTER CONSTRAINT
Previous Message Konstantin Knizhnik 2018-02-20 15:25:34 Re: Contention preventing locking