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

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>

To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>

Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>, Jesper Pedersen <jesper.pedersen@redhat.com>, David Rowley <david.rowley@2ndquadrant.com>, Simon Riggs <simon@2ndquadrant.com>, Pg Hackers <pgsql-hackers@postgresql.org>, Maksim Milyutin <milyutinma@gmail.com>

Date: 2018-01-04T17:00:58Z

Lists: pgsql-hackers

On Thu, Jan 4, 2018 at 11:44 AM, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
> I'm not sure why this feature of automatically picking up matching
> indexes even exists.  Is it for some specific workflows or upgrade
> scenarios?  It's kind of a surprising feature in a way.

It allows you to avoid building a new indexes unnecessarily when
attaching a partition.

> The catalog representations of partitioned tables and partitioned
> indexes are completely different, which may or may not be desirable.

How so?

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

Commits

Local partitioned indexes
- 8b08f7d4820f 11.0 landed
Fix StoreCatalogInheritance1 to use 32bit inhseqno
- 1ef61ddce908 11.0 landed
- 9a215fb4b5ec 9.3.21 landed
- 8a71ee628854 9.6.7 landed
- 61f08c016322 10.2 landed
- 1284d18b5de9 9.4.16 landed
- 0d993709a773 9.5.11 landed
Get rid of copy_partition_key
- 8a0596cb656e 11.0 landed
Simplify index_[constraint_]create API
- a61f5ab98638 11.0 landed