On Thu, Jul 18, 2019 at 4:50 PM Amit Langote <amitlangot...@gmail.com> wrote: > On Thu, Jul 18, 2019 at 2:53 PM Andres Freund <and...@anarazel.de> wrote: > > On 2019-07-18 14:24:29 +0900, Amit Langote wrote: > > > On Thu, Jul 18, 2019 at 10:09 AM Andres Freund <and...@anarazel.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
v1-0001-Reduce-es_result_relation_info-usage.patch
Description: Binary data
v1-0002-Rearrange-partition-update-row-movement-code-a-bi.patch
Description: Binary data
