Re: pgsql: Try again to fix the way the scanjoin_target is used with partia

On Sat, Jun 18, 2016 at 7:06 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> writes:
> > On Sat, Jun 18, 2016 at 6:11 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> Was this supposed to fix the "ORDER/GROUP BY expression not found in
> >> targetlist" problem?
> >> If so, it hasn't ...
>
> > Can you please share why you think so?
>
> Run the regression tests with the settings mentioned in
> https://www.postgresql.org/message-id/22782.1466100870@sss.pgh.pa.us
>
> You'll get a lot of cosmetic diffs (parallelized plans in EXPLAIN
> and/or varying output row orders), but also half a dozen of the
> aforesaid failure.
>

I think I got the reason of those failures.

+ /*
+ * We can't use apply_projection_to_path() here, because
there
+ * could already be pointers to these paths, and therefore
we
+ * cannot modify them in place. Instead, we must use
+ * create_projection_path(). The good news is this won't
+ * actually insert a Result node into the final plan unless
+ * it's needed, but the bad news is that it will charge for
+ * the node whether it's needed or not. Therefore, if the
+ * target list is already what we need it to be, just leave
+ * this partial path alone.
+ */
+ if (equal(scanjoin_target->exprs,
subpath->pathtarget->exprs))
+ continue;

This condition is incomplete with respect to PathTarget. What if target
exprs are same, but sortgrouprefs doesn't tally? I will try with by
modifying above condition to include sortgrouprefs as well.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com