Re: Identity projection - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Identity projection
Date
Msg-id 003201ce2134$90491e10$b0db5a30$@kapila@huawei.com
Whole thread Raw
In response to Re: Identity projection  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thursday, March 14, 2013 8:35 PM Tom Lane wrote:
> I'm starting to review this patch now, and I'm having a hard time with
> this particular design decision:
> 
> Amit Kapila <amit.kapila@huawei.com> writes:
> > We cannot directly compare expressions in target list as even if
> expressions
> > are equal, below node (ex. APPEND) will
> > not do projection, and hence expr will not be evaluated.
> 
> I think this is nonsense.  Whatever the tlist of the lower node is,
> that
> is supposed to describe what it's going to return.  That node might not
> be able to do projection, but that doesn't mean that something
> underneath it didn't.  So I think this patch is missing a bet by not
> accepting equal() expressions.  Did you have a test case showing that
> this wouldn't work?

I have missed the point that lower nodes would have done the expression
evaluation during projection.
But I think before your checkin, below comment in grouping planner might be
misleading:

/*                                 * If the top-level plan node is one that
cannot do expression                                 * evaluation, we must insert a Result node
to project the                                 * desired tlist.                                 */

Now because top-level node cannot do expression evaluation, but some lower
node would have done it.
Here the need seems to be only in case when the top-level plan node tlist is
not desired tlist.
Why do we need expression evaluation inside comment?


With Regards,
Amit Kapila.




pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [v9.3] writable foreign tables
Next
From: Amit Kapila
Date:
Subject: Re: Identity projection