Re: non-bulk inserts and tuple routing - Mailing list pgsql-hackers
From | Etsuro Fujita |
---|---|
Subject | Re: non-bulk inserts and tuple routing |
Date | |
Msg-id | 5A8652E3.9000009@lab.ntt.co.jp Whole thread Raw |
In response to | Re: non-bulk inserts and tuple routing (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>) |
Responses |
Re: non-bulk inserts and tuple routing
|
List | pgsql-hackers |
(2018/02/16 10:49), Amit Langote wrote: > On 2018/02/15 21:10, Etsuro Fujita wrote: >> here are some minor comments: >> >> o On changes to ExecCleanupTupleRouting: >> >> - ExecCloseIndices(resultRelInfo); >> - heap_close(resultRelInfo->ri_RelationDesc, NoLock); >> + if (resultRelInfo) >> + { >> + ExecCloseIndices(resultRelInfo); >> + heap_close(resultRelInfo->ri_RelationDesc, NoLock); >> + } >> >> You might check at the top of the loop whether resultRelInfo is NULL and >> if so do continue. I think that would save cycles a bit. > > Good point, done. Thanks. >> o On ExecInitPartitionInfo: >> >> + int firstVarno; >> + Relation firstResultRel; >> >> My old compiler got "variable may be used uninitialized" warnings. > > Fixed. Actually, I moved those declarations from out here into the blocks > where they're actually needed. OK, my compiler gets no warnings now. >> + /* >> + * Build the RETURNING projection if any for the partition. Note that >> + * we didn't build the returningList for each partition within the >> + * planner, but simple translation of the varattnos will suffice. >> + * This only occurs for the INSERT case; in the UPDATE/DELETE cases, >> + * ExecInitModifyTable() would've initialized this. >> + */ >> >> I think the last comment should be the same as for WCO lists: "This only >> occurs for the INSERT case or in the case of UPDATE for which we didn't >> find a result rel above to reuse." > > Fixed. The "above" is no longer needed, because there is no code left in > ExecInitPartitionInfo() to find UPDATE result rels to reuse. That code is > now in ExecSetupPartitionTupleRouting(). OK, that makes sense. >> + /* >> + * Initialize result tuple slot and assign its rowtype using the >> first >> + * RETURNING list. We assume the rest will look the same. >> + */ >> + tupDesc = ExecTypeFromTL(returningList, false); >> + >> + /* Set up a slot for the output of the RETURNING projection(s) */ >> + ExecInitResultTupleSlot(estate,&mtstate->ps); >> + ExecAssignResultType(&mtstate->ps, tupDesc); >> + slot = mtstate->ps.ps_ResultTupleSlot; >> + >> + /* Need an econtext too */ >> + if (mtstate->ps.ps_ExprContext == NULL) >> + ExecAssignExprContext(estate,&mtstate->ps); >> + econtext = mtstate->ps.ps_ExprContext; >> >> Do we need this initialization? I think we would already have the slot >> and econtext initialized when we get here. > > I think you're right. If node->returningLists is non-NULL at all, > ExecInitModifyTable() would've initialized the needed slot and expression > context. I added Assert()s to that affect. OK, but one thing I'd like to ask is: + /* + * Use the slot that would have been set up in ExecInitModifyTable() + * for the output of the RETURNING projection(s). Just make sure to + * assign its rowtype using the RETURNING list. + */ + Assert(mtstate->ps.ps_ResultTupleSlot != NULL); + tupDesc = ExecTypeFromTL(returningList, false); + ExecAssignResultType(&mtstate->ps, tupDesc); + slot = mtstate->ps.ps_ResultTupleSlot; Do we need that assignment here? > Attached updated patch. Thanks for updating the patch! Best regards, Etsuro Fujita
pgsql-hackers by date: