Horton

Re: partition routing layering in nodeModifyTable.c

Amit Langote <amitlangote09@gmail.com>

View thread View on postgr.es
From: Amit Langote <amitlangote09@gmail.com>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>, 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-28T07:46:01Z
Lists: pgsql-hackers

Attachments

On Tue, Oct 27, 2020 at 10:23 PM Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> This patch looks reasonable to me at a quick glance. I'm a bit worried
> or unhappy about the impact on FDWs, though. It doesn't seem nice that
> the ResultRelInfo is not available in the BeginDirectModify call. It's
> not too bad, the FDW can call ExecGetResultRelation() if it needs it,
> but still. Perhaps it would be better to delay calling
> BeginDirectModify() until the first modification is performed, to avoid
> any initialization overhead there, like establishing the connection in
> postgres_fdw.

Ah, calling BeginDirectModify() itself lazily sounds like a good idea;
see attached updated 0001 to see how that looks.  While updating that
patch, I realized that the ForeignScan.resultRelation that we
introduced in 178f2d560d will now be totally useless. :-(

-- 
Amit Langote
EDB: http://www.enterprisedb.com

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.