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@sss.pgh.pa.us> wrote:
>
> Amit Kapila <amit.kapila16@gmail.com> writes:
> > On Sat, Jun 18, 2016 at 6:11 AM, Tom Lane <tgl@sss.pgh.pa.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