On Wed, Feb 20, 2019 at 4:23 AM David Rowley <david.row...@2ndquadrant.com> wrote:
> On Wed, 20 Feb 2019 at 10:49, Tom Lane <t...@sss.pgh.pa.us> wrote: > > What if we dropped that idea, and instead defined the plan tree as > > returning only the columns that are updated by SET, plus the row > > identity? It would then be the ModifyTable node's job to fetch the > > original tuple using the row identity (which it must do anyway) and > > form the new tuple by combining the updated columns from the plan > > output with the non-updated columns from the original tuple. > > > > DELETE would be even simpler, since it only needs the row identity > > and nothing else. > > While I didn't look at the patch in great detail, I think this is how > Pavan must have made MERGE work for partitioned targets. I recall > seeing the tableoid being added to the target list and a lookup of the > ResultRelInfo by tableoid. > > Maybe Pavan can provide more useful details than I can. > Yes, that's the approach I took in MERGE, primarily because of the hurdles I faced in handling partitioned tables, which take entirely different route for UPDATE/DELETE vs INSERT and in MERGE we had to do all three together. But the approach also showed significant performance improvements. UPDATE/DELETE via MERGE is far quicker as compared to regular UPDATE/DELETE when there are non-trivial number of partitions. That's also a reason why I recommended doing the same for regular UPDATE/DELETE, but that got lost in the MERGE discussions. So +1 for the approach. We will need to consider how this affects EvalPlanQual which currently doesn't have to do anything special for partitioned tables. I solved that via tracking the expanded-at-the-bottom child in a separate mergeTargetRelation, but that approach has been criticised. May be Tom's idea doesn't have the same problem or most likely he will have a far better approach to address that. Thanks, Pavan -- Pavan Deolasee http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
