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