Re: [HACKERS] Proposal: Local indexes for partitioned table
David Rowley <david.rowley@2ndquadrant.com>
From: David Rowley <david.rowley@2ndquadrant.com>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
Robert Haas <robertmhaas@gmail.com>, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>, Jesper Pedersen <jesper.pedersen@redhat.com>,
Simon Riggs <simon@2ndquadrant.com>, Pg Hackers <pgsql-hackers@postgresql.org>,
Maksim Milyutin <milyutinma@gmail.com>
Date: 2018-01-05T04:08:03Z
Lists: pgsql-hackers
On 5 January 2018 at 11:01, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote: > (The more I think of this, the more I believe that pg_inherits is a > better answer. Opinions?) I admit to not having had a chance to look at any code with this yet, but I'm just thinking about a case like the following. CREATE TABLE part (a INT, b INT) PARTITION BY RANGE (a); CREATE TABLE part_a1 PARTITION OF part FOR VALUES FROM (0) TO (10) PARTITION BY RANGE (b); CREATE TABLE part_a1_b1 PARTITION OF part_a1 FOR VALUES FROM (0) TO (10); CREATE INDEX ON part_a1 (a); -- sub-partition index (creates index on part_a1_b1) CREATE INDEX ON part (a); -- What do we do here? Should we: 1. Create another identical index on part_a1_b1; or 2. Allow the existing index on part_a1_b1 to have multiple parents; or 3. ERROR... (probably not) I guess pg_index.indparentidx won't allow #2 to work. Some pg_inherits arrangement should. We don't really want to go creating indexes that we don't need to, so I think we should probably make an effort to allow #2 to work. Question is, how likely is the above scenario to take place? Normally, I see customers requiring partitioning only when an existing table grows too large for maintenance tasks to complete a reasonable timeframe. Probably there might also come a time when each of the partitions they've then gone and created also grows too large. So it does not seem unrealistic to be attaching existing tables/partitioned tables as partitions multiple times. Wanting to reuse leaf indexes for some new higher level partition parent does seem reasonable. This argument might be voided by if we allowed a DROP INDEX on part_a1 without dropping the leaf indexes. I've not checked what the patch does here, but I'd imagine if the indexes are marked as parents of that index, then they'll be dropped. I'll go off and look at the code now... -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, 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