Re: partition routing layering in nodeModifyTable.c

On Thu, Jul 18, 2019 at 4:50 PM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> On Thu, Jul 18, 2019 at 2:53 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > On 2019-07-18 14:24:29 +0900, Amit Langote wrote:
> > > On Thu, Jul 18, 2019 at 10:09 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > Or perhaps the actually correct fix is to remove es_result_relation_info
> > alltogether, and just pass it down the places that need it - we've a lot
> > more code setting it than using the value. And it'd not be hard to
> > actually pass it to the places that read it. Given all the
> > setting/resetting of it it's pretty obvious that a query-global resource
> > isn't the right place for it.
>>
> > > Would you like me to write a patch for some or all items?
> >
> > Yes, that would be awesome.
>
> OK, I will try to post a patch soon.

Attached are two patches.

The first one (0001) deals with reducing the core executor's reliance
on es_result_relation_info to access the currently active result
relation, in favor of receiving it from the caller as a function
argument. So no piece of core code relies on it being correctly set
anymore. It still needs to be set correctly for the third-party code
such as FDWs. Also, because the partition routing related suggestions
upthread are closely tied into this, especially those around
ExecInsert(), I've included them in the same patch. I chose to keep
the function ExecPrepareTupleRouting, even though it's now only called
from ExecInsert(), to preserve the readability of the latter.

The second patch (0002) implements some rearrangement of the UPDATE
tuple movement code, addressing the point 2 of in the first email of
this thread. Mainly the block of code in ExecUpdate() that implements
row movement proper has been moved in a function called ExecMove().
It also contains the cosmetic improvements suggested in point 4.

Thanks,
Amit