Re: partition routing layering in nodeModifyTable.c
Amit Langote <amitlangote09@gmail.com>
From: Amit Langote <amitlangote09@gmail.com>
To: Etsuro Fujita <etsuro.fujita@gmail.com>
Cc: Andres Freund <andres@anarazel.de>, 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-08T01:10:11Z
Lists: pgsql-hackers
Attachments
- v7-0001-Revise-BeginDirectModify-API-to-pass-ResultRelInf.patch (application/octet-stream) patch v7-0001
- v7-0002-Remove-es_result_relation_info.patch (application/octet-stream) patch v7-0002
- v7-0004-Refactor-transition-tuple-capture-code-a-bit.patch (application/octet-stream) patch v7-0004
- v7-0003-Rearrange-partition-update-row-movement-code-a-bi.patch (application/octet-stream) patch v7-0003
Fujita-san, On Wed, Aug 7, 2019 at 6:00 PM Etsuro Fujita <etsuro.fujita@gmail.com> wrote: > On Wed, Aug 7, 2019 at 4:28 PM Amit Langote <amitlangote09@gmail.com> wrote: > > I just noticed obsolete references to es_result_relation_info that > > 0002 failed to remove. One of them is in fdwhandler.sgml: > > > > <programlisting> > > TupleTableSlot * > > IterateDirectModify(ForeignScanState *node); > > </programlisting> > > > > ... The data that was actually inserted, updated > > or deleted must be stored in the > > <literal>es_result_relation_info->ri_projectReturning->pi_exprContext->ecxt_scantuple</literal> > > of the node's <structname>EState</structname>. > > > > We will need to rewrite this without mentioning > > es_result_relation_info. How about as follows: > > > > - <literal>es_result_relation_info->ri_projectReturning->pi_exprContext->ecxt_scantuple</literal> > > - of the node's <structname>EState</structname>. > > + <literal>ri_projectReturning->pi_exprContext->ecxt_scantuple</literal> > > + of the result relation's<structname>ResultRelInfo</structname> that has > > + been made available via node. > > > > I've updated 0001 with the above change. > > Good catch! Thanks for the review. > This would be nitpicking, but: > > * IIUC, we don't use the term "result relation" in fdwhandler.sgml. > For consistency with your change to the doc for BeginDirectModify, how > about using the term "target foreign table" instead of "result > relation"? Agreed, done. > * ISTM that "<structname>ResultRelInfo</structname> that has been made > available via node" would be a bit fuzzy to FDW authors. To be more > specific, how about changing it to > "<structname>ResultRelInfo</structname> passed to > <function>BeginDirectModify</function>" or something like that? That works for me, although an FDW author reading this still has got to make the connection. Attached updated patches; only 0001 changed in this version. Thanks, Amit
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