Re: [HACKERS] Proposal: Local indexes for partitioned table
Alvaro Herrera <alvherre@alvh.no-ip.org>
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: David Rowley <david.rowley@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Simon Riggs <simon@2ndquadrant.com>, Pg Hackers <pgsql-hackers@postgresql.org>, Maksim Milyutin <milyutinma@gmail.com>
Date: 2017-12-20T17:01:58Z
Lists: pgsql-hackers
Attachments
- v6-0001-Allow-indexes-on-partitioned-tables.patch (text/plain) patch v6-0001
Great, thanks for the input. pg_dump behaves as described upthread -- thanks David and Robert for the input. I did this by injecting a fake "INDEX ATTACH" object in pg_dump's model, which depends on the index-on-parent-table; which in turn depends on the index-on-partition. Because of the dependencies, the attach is dumped last, and the index-on-parent is dumped after all the indexes-on-partitions have been dumped. I needed to apply a little bit of surgery so that each table object would contain links to its indexes, which previously wasn't there. A followup step to obtaining index info creates the INDEX ATTACH objects. In the backend code: There is now a difference in initial setting of indisvalid and indisready when creating an index. Previously we always set them the same (!concurrent) but now indisready depends only on "concurrent" while indisvalid additionally depends on whether a a non-inherited index on a partitioned table is being built. Failing to set indisready to true initially was causing the index to be invisible to pg_dump. There is no ALTER INDEX / DETACH, as discussed. Also, trying to attach an index for a partition that already contains an attached index raises an error -- which means that in order to determine whether attaching an index as partition makes the parent index valid, is a simple matter of counting tuples. All these behaviors are immortalized in the regression tests. I added tab-complete support too (thanks Jesper for the reminder). It is probably not exhaustive, but should be good enough. I have two patches to rebase on top of this, which I hope to post later today: 1) let these indexes be unique (i.e. allow unique and PK constraints) 2) allow foreign keys on partitioned tables I have a further patch to allow FOR EACH ROW triggers on partitioned tables, but I think it's largely unrelated to this (and, as I was surprised to discover, it's also unrelated to the FKs one). Thanks -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
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