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: "'Heikki Linnakangas'" <hlinnakangas(at)vmware(dot)com>, "'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-03-15 04:21:27
Message-ID: 003201ce2134$90491e10$b0db5a30$@kapila@huawei.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(dot)kapila(at)huawei(dot)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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2013-03-15 04:24:13 Re: Identity projection
Previous Message Robert Haas 2013-03-15 03:20:03 Re: [v9.3] writable foreign tables