Re: [HACKERS] Initialization of ResultTupleSlot in AppendNode
That also holds the plan's output tuple descriptor. If you tried to remove it, I think the ExecAssignResultTypeFromTL call would crash. And if you removed *that*, upper nodes would get unhappy, cf ExecGetResultType. Yes, this is true. However upper nodes doesn't need in all cases, so is it possible that ExecGetResultType should check if ResultTupleSlot is NULL, then does functionality similar to ExecAssignResultTypeFromTL, to return tuple descriptor. This can save everytime allocation of ResultTupleSlot for AppendNode. *** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -Original Message- From: Tom Lane [mailto:t...@sss.pgh.pa.us] Sent: Friday, September 16, 2011 4:24 AM To: Amit Kapila Cc: pgsql-hackers@postgresql.org Subject: Re: [HACKERS] Initialization of ResultTupleSlot in AppendNode Amit Kapila amit.kap...@huawei.com writes: I observed that during initialization of planstate for Append Node, we allocate ResulttupleSlot, however it is used only to send NULL slot indicate no more tuples. Is it right or there is any other purpose of it? That also holds the plan's output tuple descriptor. If you tried to remove it, I think the ExecAssignResultTypeFromTL call would crash. And if you removed *that*, upper nodes would get unhappy, cf ExecGetResultType. The use as an end-of-scan signal seems a bit vestigial, since we could just as well return NULL, but it doesn't really cost enough to be worth changing ... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Initialization of ResultTupleSlot in AppendNode
That also holds the plan's output tuple descriptor. If you tried to remove it, I think the ExecAssignResultTypeFromTL call would crash. And if you removed *that*, upper nodes would get unhappy, cf ExecGetResultType. Yes, this is true. However upper nodes doesn't need in all cases, so is it possible that ExecGetResultType should check if ResultTupleSlot is NULL, then does functionality similar to ExecAssignResultTypeFromTL, to return tuple descriptor. This can save everytime allocation of ResultTupleSlot for AppendNode. *** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -Original Message- From: Tom Lane [mailto:t...@sss.pgh.pa.us] Sent: Friday, September 16, 2011 4:24 AM To: Amit Kapila Cc: pgsql-hackers@postgresql.org Subject: Re: [HACKERS] Initialization of ResultTupleSlot in AppendNode Amit Kapila amit.kap...@huawei.com writes: I observed that during initialization of planstate for Append Node, we allocate ResulttupleSlot, however it is used only to send NULL slot indicate no more tuples. Is it right or there is any other purpose of it? That also holds the plan's output tuple descriptor. If you tried to remove it, I think the ExecAssignResultTypeFromTL call would crash. And if you removed *that*, upper nodes would get unhappy, cf ExecGetResultType. The use as an end-of-scan signal seems a bit vestigial, since we could just as well return NULL, but it doesn't really cost enough to be worth changing ... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Initialization of ResultTupleSlot in AppendNode
Hi All, I observed that during initialization of planstate for Append Node, we allocate ResulttupleSlot, however it is used only to send NULL slot indicate no more tuples. Is it right or there is any other purpose of it? Amit *** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
Re: [HACKERS] Initialization of ResultTupleSlot in AppendNode
Amit Kapila amit.kap...@huawei.com writes: I observed that during initialization of planstate for Append Node, we allocate ResulttupleSlot, however it is used only to send NULL slot indicate no more tuples. Is it right or there is any other purpose of it? That also holds the plan's output tuple descriptor. If you tried to remove it, I think the ExecAssignResultTypeFromTL call would crash. And if you removed *that*, upper nodes would get unhappy, cf ExecGetResultType. The use as an end-of-scan signal seems a bit vestigial, since we could just as well return NULL, but it doesn't really cost enough to be worth changing ... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
