Re: Add support for tuple routing to foreign partitions

From: Maksim Milyutin <milyutinma(at)gmail(dot)com>
To: Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>, Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
Subject: Re: Add support for tuple routing to foreign partitions
Date: 2017-10-02 12:37:17
Message-ID: 17263002-b5a9-37f1-3650-c4ba2882bf6f@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Fujita-san!

On 11.09.2017 16:01, Etsuro Fujita wrote:
> Here is an updated version of the patch.
>
> * Query planning: the patch creates copies of Query/Plan with a
> foreign partition as target from the original Query/Plan for each
> foreign partition and invokes PlanForeignModify with those copies, to
> allow the FDW to do query planning for remote INSERT with the existing
> API.  To make such Queries the similar way inheritance_planner does, I
> modified transformInsertStmt so that the inh flag for the partitioned
> table's RTE is set to true, which allows (1) expand_inherited_rtentry
> to build an RTE and AppendRelInfo for each partition in the
> partitioned table and (2) make_modifytable to build such Queries using
> adjust_appendrel_attrs and those AppendRelInfos.
>
> * explain.c: I modified show_modifytable_info so that we can show
> remote queries for foreign partitions in EXPLAIN for INSERT into a
> partitioned table the same way as for inherited 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)
>
> I think I should add more explanation about the patch, but I don't
> have time today, so I'll write additional explanation in the next
> email. Sorry about that.

Could you update your patch, it isn't applied on the actual state of
master. Namely conflict in src/backend/executor/execMain.c

--
Regards,
Maksim Milyutin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Maksim Milyutin 2017-10-02 12:43:45 Re: [BUG] Cache invalidation for queries that contains const of temporary composite type
Previous Message Daniel Gustafsson 2017-10-02 12:24:41 Re: Fix number skipping in to_number