Horton

Re: [HACKERS] Proposal: Local indexes for partitioned table

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: David Rowley <david.rowley@2ndquadrant.com>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>, Simon Riggs <simon@2ndquadrant.com>, Pg Hackers <pgsql-hackers@postgresql.org>, Maksim Milyutin <milyutinma@gmail.com>
Date: 2017-12-05T22:35:31Z
Lists: pgsql-hackers 
On Tue, Dec 5, 2017 at 3:53 PM, David Rowley
<david.rowley@2ndquadrant.com> wrote:
> I'm not hugely concerned about that. It's not a new problem and it's
> not a problem that I recall seeing anyone complain about, at least not
> to the extent that we've ever bothered to fix it.
>
> The existing problem is with FOREIGN KEY constraints just choosing the
> first matching index in transformFkeyCheckAttrs()
>
> We can see the issue today with:
>
> create table t1 (id int not null);
> create unique index t1_idx_b on t1 (id);
> create table t2 (id int references t1 (id));
> create unique index t1_idx_a on t1 (id);
>
> <pg_dump>
> <pg_restore>
>
> # drop index t1_idx_a;
> ERROR:  cannot drop index t1_idx_a because other objects depend on it
> DETAIL:  constraint t2_id_fkey on table t2 depends on index t1_idx_a
> HINT:  Use DROP ... CASCADE to drop the dependent objects too.

Ugh, that sucks.  I don't think it's a good argument for making the
problem worse, though.  What are we giving up by explicitly attaching
the correct index?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Commits

  1. Local partitioned indexes

  2. Fix StoreCatalogInheritance1 to use 32bit inhseqno

  3. Get rid of copy_partition_key

  4. Simplify index_[constraint_]create API