On 19/10/2020 07:54, Amit Langote wrote:
On Sun, Oct 18, 2020 at 12:54 AM Alvaro Herrera <alvhe...@alvh.no-ip.org> wrote:
On 2020-Oct-17, Amit Langote wrote:
Hmm, I don't see ri_PartitionCheckExpr as being a piece of routing
information, because it's primarily meant to be used when inserting
*directly* into a partition, although it's true we do initialize it in
routing target partitions too in some cases.
Also, ChildToRootMap was introduced by the trigger transition table
project, not tuple routing. I think we misjudged this when we added
PartitionToRootMap to PartitionRoutingInfo, because it doesn't really
belong there. This patch fixes that by removing PartitionToRootMap.
RootToPartitionMap and the associated partition slot is the only piece
of extra information that is needed by tuple routing target relations.
Well, I was thinking on making the ri_PartitionInfo be about
partitioning in general, not just specifically for partition tuple
routing. Maybe Heikki is right that it may end up being simpler to
remove ri_PartitionInfo altogether. It'd just be a couple of additional
pointers in ResultRelInfo after all.
So that's 2 votes for removing PartitionRoutingInfo from the tree.
Okay, I have tried that in the attached 0002 patch. Also, I fixed
some comments in 0001 that still referenced PartitionToRootMap.
Pushed, with minor comment changes.
I also noticed that the way the getTargetResultRelInfo() helper function
was used, was a bit messy. It was used when firing AFTER STATEMENT
triggers, but for some reason the code to fire BEFORE STATEMENT triggers
didn't use it but duplicated the logic instead. I made that a bit
simpler, by always setting the rootResultRelInfo field in
ExecInitModifyTable(), making the getTargetResultRelInfo() function
unnecessary.
Thanks!
- Heikki
