Re: ERROR: ORDER/GROUP BY expression not found in targetlist

From: Amit Kapila <amit(dot)kapila(at)enterprisedb(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ERROR: ORDER/GROUP BY expression not found in targetlist
Date: 2016-06-17 02:48:36
Message-ID: CA+kptmBc0sBShAce5thubBae3j8fq_PJcV_jL=VMAkCGk3y9Vg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jun 17, 2016 at 3:20 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Thu, Jun 16, 2016 at 12:16 PM, Robert Haas <robertmhaas(at)gmail(dot)com>
wrote:
> > On Thu, Jun 16, 2016 at 8:00 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
wrote:
> >>> 1. The case originally reported by Thomas Munro still fails. To fix
> >>> that, we probably need to apply scanjoin_target to each partial path.
> >>> But we can only do that if it's parallel-safe. It seems like what we
> >>> want is something like this: (1) During scan/join planning, somehow
> >>> skip calling generate_gather_paths for the topmost scan/join rel as we
> >>> do to all the others. (2) If scanjoin_target is not parallel-safe,
> >>> build a path for the scan/join phase that applies a Gather node to the
> >>> cheapest path and does projection at the Gather node. Then forget all
> >>> the partial paths so we can't do any bogus upper planning. (3) If
> >>> scanjoin_target is parallel-safe, replace the list of partial paths
> >>> for the topmost scan/join rel with a new list where scanjoin_target
> >>> has been applied to each one. I haven't tested this so I might be
> >>> totally off-base about what's actually required here...
> >>
> >> I think we can achieve it just by doing something like what you have
> >> mentioned in (2) and (3). I am not sure if there is a need to skip
> >> generation of gather paths for top scan/join node. Please see the
patch
> >> attached. I have just done some minimal testing to ensure that problem
> >> reported by Thomas Munro in this thread is fixed and verified that the
fix
> >> is sane for problems [1][2] reported by sqlsmith. If you think this is
on
> >> right lines, I can try to do more verification and try to add tests.
> >
> > You can't do it this way because of the issue Tom discussed here:
> >
> > https://www.postgresql.org/message-id/16421.1465828862@sss.pgh.pa.us
>

I think although we are always adding a projection path in
apply_projection_to_path() to subpath of Gather path if target is parallel
safe, still they can be used directly if create_projection_plan() doesn't
add a Result node. So changing them directly after being pushed below
Gather is not a safe bet.

> Something like what you have there might work if you use
> create_projection_path instead of apply_projection_to_path.
>

Okay, I think you mean to say use create_projection_path() while applying
scanjoin_target to partial path lists in below code:
foreach(lc, current_rel->partial_pathlist)
{
Path *subpath = (Path *) lfirst(lc);
Assert(subpath->param_info == NULL);
lfirst(lc) = apply_projection_to_path(root, current_rel,
subpath, scanjoin_target,
scanjoin_target_parallel_safe);
}

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2016-06-17 03:23:03 Re: ERROR: ORDER/GROUP BY expression not found in targetlist
Previous Message Etsuro Fujita 2016-06-17 02:44:09 Re: [sqlsmith] Failed assertion in postgres_fdw/deparse.c:1116