Horton

Re: partition routing layering in nodeModifyTable.c

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Etsuro Fujita <etsuro.fujita@gmail.com>
Cc: Amit Langote <amitlangote09@gmail.com>, 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-03T17:32:36Z
Lists: pgsql-hackers 
Hi,

On 2019-08-03 19:41:55 +0900, Etsuro Fujita wrote:
> > I don't like
> > ExecFindResultRelInfo at all. What's the point of it? It's introduction
> > is still an API break - I don't understand why that break is better than
> > just passing the ResultRelInfo directly to BeginDirectModify()?
> 
> What API does that function break?

You need to call it, whereas previously you did not need to call it. The
effort to change an FDW to get one more parameter, or to call that
function is about the same.

Greetings,

Andres Freund

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.