Re: partition routing layering in nodeModifyTable.c
Etsuro Fujita <etsuro.fujita@gmail.com>
From: Etsuro Fujita <etsuro.fujita@gmail.com>
To: Amit Langote <amitlangote09@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-08T12:49:09Z
Lists: pgsql-hackers
Attachments
- v7-0001-Remove-dependency-on-estate-es_result_relation_info-efujita.patch (application/octet-stream) patch v7-0001
Hi, On Thu, Aug 8, 2019 at 10:10 AM Amit Langote <amitlangote09@gmail.com> wrote: > 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. > > 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 for the updated version, Amit-san! I updated the 0001 patch a bit further: * Tweaked comments in plannodes.h, createplan.c, and nodeForeignscan.c. * Made cosmetic changes to postgres_fdw.c. * Adjusted doc changes a bit, mainly not to produce unnecessary diff. * Modified the commit message. Attached is an updated version of the 0001 patch. Does that make sense? Best regards, Etsuro Fujita
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