Date: Tue, 14 Nov 2017 13:09:46 +0100
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: David Rowley <david.rowley@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>,
	Pg Hackers <pgsql-hackers@postgresql.org>,
	Maksim Milyutin <m.milyutin@postgrespro.ru>
Subject: Re: [HACKERS] Proposal: Local indexes for partitioned table
Message-ID: <20171114120946.ovsswdfl34ob6ag2@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CAKJS1f_o6v+XtT+3gfieUdCiU5Sn84humT-CVW5So_x_f=kLxQ@mail.gmail.com>
User-Agent: NeoMutt/20170306-137-4415bd-dirty (1.8.0)
Precedence: bulk

Thanks for looking.

David Rowley wrote:

> So, if that works for ATTACH, then can't pg_dump just
> create each of the partition's indexes first, then create the
> partitioned table's partition index, and that command would just go
> through checking each partition similar to how ATTACH would work.

That was my first thought too (and I actually implemented it like this
before the current approach).  But there's a small problem: if a
partition exists which *doesn't* have the index, restoring things this
way would create the index in that partition too, which is unwanted
because the end state is different to what was in the dumped database.
This is because the command is either recursive (finds a matching index
and attachs it, or create a new one) or not recursive (does not look at
children at all).  But a command that is partially recursive (attach any
matching index, but do nothing if none exists) would be way too
confusing, ISTM.

Another small issue is that each partition might have two matching
indexes, maybe because one was in the process of being removed; how
would CREATE INDEX at restore time know which one to attach?  It could
do so by choosing arbitrarily, but that doesn't seem reliable.

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