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
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 |
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 |