Re: expanding inheritance in partition bound order
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
Cc: Amit Khandekar <amitdkhan.pg@gmail.com>,
Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2017-08-30T03:03:34Z
Lists: pgsql-hackers
On Tue, Aug 29, 2017 at 10:36 PM, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> wrote: >> I keep having the feeling that this is a big patch with a small patch >> struggling to get out. Is it really necessary to change >> RelationGetPartitionDispatchInfo so much or could you just do a really >> minimal surgery to remove the code that sets the stuff we don't need? >> Like this: > > Sure, done in the attached updated patch. On first glance, that looks pretty good. I'll have a deeper look tomorrow. It strikes me that if PartitionTupleRoutingInfo is an executor structure, we should probably (as a separate patch) relocate FormPartitionKeyDatum and get_partition_for_tuple to someplace in src/backend/executor and rename the accordingly; maybe it's time for an execPartition.c? catalog/partition.c is getting really bug, so it's not a bad thing if some of that stuff gets moved elsewhere. A lingering question in my mind, though, is whether it's really correct to think of PartitionTupleRoutingInfo as executor-specific. Maybe we're going to need that for other things too? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Commits
-
Make RelationGetPartitionDispatchInfo expand depth-first.
- 77b6b5e9ceca 11.0 landed
-
Expand partitioned tables in PartDesc order.
- 30833ba154e0 11.0 landed
-
Don't lock tables in RelationGetPartitionDispatchInfo.
- 7c0ca2900f7c 10.0 landed
- 54cde0c4c058 11.0 landed
-
Speed up dropping tables with many partitions.
- c1e0e7e1d790 10.0 cited