Re: Identity projection

From: Amit Kapila <amit(dot)kapila(at)huawei(dot)com>
To: "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <hlinnaka(at)iki(dot)fi>, "'Kyotaro HORIGUCHI'" <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Identity projection
Date: 2013-02-08 11:47:15
Message-ID: 005c01ce05f2$0ac9e0b0$205da210$@kapila@huawei.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Friday, February 08, 2013 12:00 AM Tom Lane wrote:
> Amit Kapila <amit(dot)kapila(at)huawei(dot)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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2013-02-08 11:47:22 Re: [PATCH] Add Makefile dep in bin/scripts for libpgport
Previous Message Dave Cramer 2013-02-08 11:33:15 Re: [HACKERS] JPA + enum == Exception