You signed in with another tab or window.Reload to refresh your session.You signed out in another tab or window.Reload to refresh your session.You switched accounts on another tab or window.Reload to refresh your session.Dismiss alert
Don't require return slots for nodes without projection.
In a lot of nodes the return slot is not required. That can either bebecause the node doesn't do any projection (say an Append node), orbecause the node does perform projections but the projection isoptimized away because the projection would yield an identical row.Slots aren't that small, especially for wide rows, so it's worthwhileto avoid creating them. It's not possible to just skip creating theslot - it's currently used to determine the tuple descriptor returnedby ExecGetResultType(). So separate the determination of the resulttype from the slot creation. The work previously done internallyExecInitResultTupleSlotTL() can now also be done separately withExecInitResultTypeTL() and ExecInitResultSlot(). That way nodes thataren't guaranteed to need a result slot, can useExecInitResultTypeTL() to determine the result type of the node, andExecAssignScanProjectionInfo() (viaExecConditionalAssignProjectionInfo()) determines that a result slotis needed, it is created with ExecInitResultSlot().Besides the advantage of avoiding to create slots that then areunused, this is necessary preparation for later patches around tupletable slot abstraction. In particular separating the return descriptorand slot is a prerequisite to allow JITing of tuple deforming withknowledge of the underlying tuple format, and to avoid unnecessarilycreating JITed tuple deforming for virtual slots.This commit removes a redundant argument fromExecInitResultTupleSlotTL(). While this commit touches a lot of therelevant lines anyway, it'd normally still not worthwhile to causebreakage, except that aforementioned later commits will touch *all*ExecInitResultTupleSlotTL() callers anyway (but fits worsethematically).Author: Andres FreundDiscussion:https://postgr.es/m/20181105210039.hh4vvi4vwoq5ba2q@alap3.anarazel.de