From: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)com>, Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] Useless code in ExecInitModifyTable |
Date: | 2018-01-19 10:14:14 |
Message-ID: | e7ff65ef-3ca0-818e-18f3-9512c139be94@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2018/01/19 18:50, Amit Khandekar wrote:
> FYI ...
>
> For the pending update-partition-key patch, we would again require the
> rel variable for UPDATE. So in the rebased update-partition-key patch
> [1], 'rel' is assigned the root partitioned table. But this time, I
> have used the already opened node->rootResultRelInfo to get the root
> partitioned table, rather than opening it again. Details : [1] . Sorry
> for not noticing this potential conflict earlier. Comments welcome.
>
> [1] : https://www.postgresql.org/message-id/CAJ3gD9cpyM1L0vTrXzrggR%3Dt6MSZtuy_kge1kagMBi0TSKa_UQ%40mail.gmail.com
That's nice. Actually, the rootResultRelInfo field was introduced [1]
after partitioned_rels [2] and the code that got removed with the patch
that was committed should have gone much earlier. That is, when
rootResultRelInfo was introduced, but then again as Fujita-san pointed
out, there wasn't much point then (and now) to finding the root table's
Relation pointer in some special place. But now we need to, for the
update tuple routing case as you said.
Thanks,
Amit
[1]
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=e180c8aa8ca
[2]
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=d3cc37f1d801
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2018-01-19 10:31:47 | Re: [PATCH] session_replication_role = replica with TRUNCATE |
Previous Message | Simon Riggs | 2018-01-19 10:07:47 | Re: Rangejoin rebased |