[HACKERS] Add support for tuple routing to foreign partitions - Mailing list pgsql-hackers

From Etsuro Fujita
Subject [HACKERS] Add support for tuple routing to foreign partitions
Date
Msg-id 29906a26-da12-8c86-4fb9-d8f88442f2b9@lab.ntt.co.jp
Whole thread Raw
Responses Re: [HACKERS] Add support for tuple routing to foreign partitions
Re: [HACKERS] Add support for tuple routing to foreign partitions
List pgsql-hackers
Hi,

Here is a patch for $subject.  This is based on Amit's original patch 
(patch '0007-Tuple-routing-for-partitioned-tables-15.patch' in [1]). 
Main changes are:

* I like Amit's idea that for each partition that is a foreign table, 
the FDW performs query planning in the same way as in non-partition 
cases, but the changes to make_modifytable() in the original patch that 
creates a working-copy of Query to pass to PlanForeignModify() seem 
unacceptable.  So, I modified the changes so that we create 
more-valid-looking copies of Query and ModifyTable with the foreign 
partition as target, as I said before.  In relation to this, I also 
allowed expand_inherited_rtentry() to build an RTE and AppendRelInfo for 
each partition of a partitioned table that is an INSERT target, as 
mentioned by Amit in [1], by modifying transformInsertStmt() so that we 
set the inh flag for the target table's RTE to true when the target 
table is a partitioned table.  The partition RTEs are not only 
referenced by FDWs, but used in selecting relation aliases for EXPLAIN 
(see below) as well as extracting plan dependencies in setref.c so that 
we force rebuilding of the plan on any change to partitions.  (We do 
replanning on FDW table-option changes to foreign partitions, currently. 
  See regression tests in the attached patch.)

* The original patch added tuple routing to foreign partitions in COPY 
FROM, but I'm not sure the changes to BeginCopy() in the patch are the 
right way to go.  For example, the patch passes a dummy empty Query to 
PlanForeignModify() to make FDWs perform query planning, but I think 
FDWs would be surprised by the Query.  Currently, we don't support COPY 
to foreign tables, so ISTM that it's better to revisit this issue when 
adding support for COPY to foreign tables.  So, I dropped the COPY part.

* I modified explain.c so that EXPLAIN for an INSERT into a partitioned 
table displays partitions just below the ModifyTable node, and shows 
remote queries for foreign partitions in the same way as EXPLAIN for 
UPDATE/DELETE cases.  Here is an example:

postgres=# explain verbose insert into pt values (1), (2);
                             QUERY PLAN
-------------------------------------------------------------------
  Insert on public.pt  (cost=0.00..0.03 rows=2 width=4)
    Foreign Insert on public.fp1
      Remote SQL: INSERT INTO public.t1(a) VALUES ($1)
    Foreign Insert on public.fp2
      Remote SQL: INSERT INTO public.t2(a) VALUES ($1)
    ->  Values Scan on "*VALUES*"  (cost=0.00..0.03 rows=2 width=4)
          Output: "*VALUES*".column1
(7 rows)

Comments are welcome!  Anyway, I'll add this to the next commitfest.

Best regards,
Etsuro Fujita

[1] 
https://www.postgresql.org/message-id/aa874eaf-cd3b-0f75-c647-6c0ea823781e%40lab.ntt.co.jp

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Attachment

pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: [HACKERS] What does it mean by XLOG_BACKUP_RECORD?
Next
From: Etsuro Fujita
Date:
Subject: Re: [HACKERS] Declarative partitioning - another take