Re: partition routing layering in nodeModifyTable.c
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Etsuro Fujita <etsuro.fujita@gmail.com>
Cc: Amit Langote <amitlangote09@gmail.com>, Thomas Munro <thomas.munro@gmail.com>, David Rowley <david.rowley@2ndquadrant.com>, Robert Haas <robertmhaas@gmail.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>, PostgreSQL-development <pgsql-hackers@postgresql.org>, amitdkhan.pg@gmail.com
Date: 2019-08-02T20:30:59Z
Lists: pgsql-hackers
Hi, On 2019-08-03 05:20:35 +0900, Etsuro Fujita wrote: > On Sat, Aug 3, 2019 at 3:01 AM Andres Freund <andres@anarazel.de> wrote: > > On 2019-07-31 17:04:38 +0900, Amit Langote wrote: > > > I looked into trying to do the things I mentioned above and it seems > > > to me that revising BeginDirectModify()'s API to receive the > > > ResultRelInfo directly as Andres suggested might be the best way > > > forward. I've implemented that in the attached 0001. > > > Fujita-san, do you have any comments on the FDW API change? Or anybody > > else? > > > > I'm a bit woried about the move of BeginDirectModify() into > > nodeModifyTable.c - it just seems like an odd control flow to me. Not > > allowing any intermittent nodes between ForeignScan and ModifyTable also > > seems like an undesirable restriction for the future. I realize that we > > already do that for BeginForeignModify() (just btw, that already accepts > > resultRelInfo as a parameter, so being symmetrical for BeginDirectModify > > makes sense), but it still seems like the wrong direction to me. > > > > The need for that move, I assume, comes from needing knowing the correct > > ResultRelInfo, correct? I wonder if we shouldn't instead determine the > > at plan time (in setrefs.c), somewhat similar to how we determine > > ModifyTable.resultRelIndex. Doesn't look like that'd be too hard? > > I'd vote for that; I created a patch for that [1]. > > [1] https://www.postgresql.org/message-id/CAPmGK15%3DoFHmWNND5vopfokSGfn6jMXVvnHa7K7P49F7k1hWPQ%40mail.gmail.com Oh, missed that. But that's not quite what I'm proposing. I don't like ExecFindResultRelInfo at all. What's the point of it? It's introduction is still an API break - I don't understand why that break is better than just passing the ResultRelInfo directly to BeginDirectModify()? I want to again remark that BeginForeignModify() does get the ResultRelInfo - it should have been done the same when adding direct modify. Even if you need the loop - which I don't think is right - it should live somewhere that individual FDWs don't have to care about. - Andres
Commits
-
Fix initialization of es_result_relations in EvalPlanQualStart().
- 22b73d3cb0b5 14.0 landed
-
Remove PartitionRoutingInfo struct.
- fb5883da8615 14.0 landed
-
Revise child-to-root tuple conversion map management.
- 6973533650c0 14.0 landed
-
Clean up code to resolve the "root target relation" in nodeModifyTable.c
- f49b85d783f6 14.0 landed
-
Refactor code for cross-partition updates to a separate function.
- c5b097f8fa69 14.0 landed
-
Remove es_result_relation_info from EState.
- a04daa97a433 14.0 landed
-
Include result relation info in direct modify ForeignScan nodes.
- 178f2d560dde 14.0 landed
-
Create ResultRelInfos later in InitPlan, index them by RT index.
- 1375422c7826 14.0 landed