Horton

Re: partition routing layering in nodeModifyTable.c

Heikki Linnakangas <hlinnaka@iki.fi>

View thread View on postgr.es
From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Amit Langote <amitlangote09@gmail.com>
Cc: Daniel Gustafsson <daniel@yesql.se>, Etsuro Fujita <etsuro.fujita@gmail.com>, Andres Freund <andres@anarazel.de>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2020-10-13T16:30:28Z
Lists: pgsql-hackers

Attachments

On 13/10/2020 19:09, Heikki Linnakangas wrote:
> One little idea I had:
> 
> I think all FDWs that support direct modify will have to carry the
> resultRelaton index or the ResultRelInfo pointer from BeginDirectModify
> to IterateDirectModify in the FDW's private struct. It's not
> complicated, but should we make life easier for FDWs by storing the
> ResultRelInfo pointer in the ForeignScanState struct in the core code?
> The doc now says:
> 
>> The data that was actually inserted, updated or deleted must be
>> stored in the ri_projectReturning->pi_exprContext->ecxt_scantuple of
>> the target foreign table's ResultRelInfo obtained using the
>> information passed to BeginDirectModify. Return NULL if no more rows
>> are available.
> 
> That "ResultRelInfo obtained using the information passed to
> BeginDirectModify" part is a pretty vague. We could expand it, but if we
> stored the ResultRelInfo in the ForeignScanState, we could explain it
> succinctly.

I tried that approach, see attached. Yeah, this feels better to me.

- Heikki

Commits

  1. Fix initialization of es_result_relations in EvalPlanQualStart().

  2. Remove PartitionRoutingInfo struct.

  3. Revise child-to-root tuple conversion map management.

  4. Clean up code to resolve the "root target relation" in nodeModifyTable.c

  5. Refactor code for cross-partition updates to a separate function.

  6. Remove es_result_relation_info from EState.

  7. Include result relation info in direct modify ForeignScan nodes.

  8. Create ResultRelInfos later in InitPlan, index them by RT index.