Re: Identity projection - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Identity projection
Date
Msg-id 005c01ce05f2$0ac9e0b0$205da210$@kapila@huawei.com
Whole thread Raw
In response to Re: Identity projection  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Identity projection  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Friday, February 08, 2013 12:00 AM Tom Lane wrote:
> Amit Kapila <amit.kapila@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.

So for this, if a,b,c (below mentioned conds.) are true then don't create
Result Plan, just return subplan
a. subplan is NOT NULL and 
b. resconstantqual is NULL and
c. compare expr of each TargetEntry for proposed tlist with subplan target 


> 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.

As per my understanding, currently in code wherever Result node can be
avoided, 
it calls function is_projection_capable_plan(), so we can even enhance
is_projection_capable_plan()
so that it can also verify the expressions of tlists. But for this we need
to change at all places 
from where is_projection_capable_plan() is called.

With Regards,
Amit Kapila.




pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: [PATCH] Add Makefile dep in bin/scripts for libpgport
Next
From: Seamus Abshere
Date:
Subject: Re: Alias hstore's ? to ~ so that it works with JDBC