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

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
Cc: Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Maksim Milyutin <milyutinma(at)gmail(dot)com>
Subject: Re: [HACKERS] Proposal: Local indexes for partitioned table
Date: 2017-12-28 21:53:04
Message-ID: 20171228215304.twephgpycnt7s5gz@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Amit Langote wrote:

> 2. Something strange about how dependencies are managed:
> create table p (a char) partition by list (a);
> create table pa partition of p for values in ('a');;
> create table pb partition of p for values in ('b');
> create index on p (a);

> drop table pa;
> ERROR: cannot drop table pa because other objects depend on it
> DETAIL: index p_a_idx depends on table pa
> HINT: Use DROP ... CASCADE to drop the dependent objects too.

Hmm, this is quite nasty and I'm not seeing any reasonable way to fix
it. The problem is that we have an internal dep from the parent index
to the partition index, which prompts us to recurse the chase of
dependencies inverting the way the dependencies flow -- the "case 3" in
* 3. Not all the owning objects have been visited, so
* transform this deletion request into a delete of this
* owning object.

The problem is that we don't want the partition index to go away unless
it's together with its parent index, except if the table which contains
it goes away first. We have no way to specify this condition ... Maybe
something like sticking a phony additional record in pg_depend that
causes the partition index to get added to the targetObjects list ahead
of time ... but that doesn't work either, because we still want to chase
the internal deps in that case. Hm.

Maybe we need a new "auto internal" deptype with a mix of semantics of
the other two deptypes. It seems a bit ugly and I'm not sure it'd work
either ... I'll try to code it tomorrow.

Álvaro Herrera
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2017-12-28 22:03:23 Re: [HACKERS] pgbench more operators & functions
Previous Message David Rowley 2017-12-28 21:24:14 Re: pg_(total_)relation_size and partitioned tables