Amit Kapila <amit.kap...@huawei.com> writes:
> There can be 2 ways to remove result node
> a. Remove the Result plan node in case it is not required - This is same as
> currently it does for SubqueryScan.
> We can check if the result plan is trivial (with logic similar to
> trivial_subqueryscan()), then remove result node.
> b. to avoid adding it to Plan node in case it is not required -
> For this, in grouping_planner() currently it checks if the plan is
> projection capable (is_projection_capable_plan()),
> we can enhance this check such that it also check projection is really
> required depending if the targetlist contains
> any non Var element.
> Please suggest which way is more preferable and if one of above 2 seems to
> be okay,
Adding a result node only to remove it again seems a bit expensive.
It'd be better not to generate the node in the first place. (There's
a technical reason to generate a temporary SubqueryScan, which is to
keep Var numbering in the subplan separate from that in the upper plan;
but AFAICS that doesn't apply to Result.)
An advantage of removing useless Results at setrefs.c time is that we
can be sure it will be applied to all Result nodes. However, we might
be able to do it the other way with only one point-of-change if we hack
make_result itself to check whether the proposed tlist is an identity.
Note that "contains non Var element" is the wrong test for this anyway
--- the question is does the tlist have the same expressions in the same
order as the tlist of the Result's child node.
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
