Re: ERROR: ORDER/GROUP BY expression not found in targetlist - Mailing list pgsql-hackers

From Tom Lane
Subject Re: ERROR: ORDER/GROUP BY expression not found in targetlist
Date
Msg-id 20391.1465850779@sss.pgh.pa.us
Whole thread Raw
In response to Re: ERROR: ORDER/GROUP BY expression not found in targetlist  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: ERROR: ORDER/GROUP BY expression not found in targetlist
Re: ERROR: ORDER/GROUP BY expression not found in targetlist
Re: ERROR: ORDER/GROUP BY expression not found in targetlist
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> In practice, we don't yet have the ability for
> parallel-safe paths from subqueries to affect planning at higher query
> levels, but that's because the pathification stuff landed too late in
> the cycle for me to fully react to it.

I wonder if that's not just from confusion between subplans and
subqueries.  I don't believe any of the claims made in the comment
adjusted in the patch below (other than "Subplans currently aren't passed
to workers", which is true but irrelevant).  Nested Gather nodes is
something that you would need, and already have, a defense for anyway.

            regards, tom lane


diff --git a/src/backend/optimizer/path/allpaths.c b/src/backend/optimizer/path/allpaths.c
index cc8ba61..8ab049c 100644
*** a/src/backend/optimizer/path/allpaths.c
--- b/src/backend/optimizer/path/allpaths.c
*************** set_rel_consider_parallel(PlannerInfo *r
*** 560,574 ****
          case RTE_SUBQUERY:

              /*
!              * Subplans currently aren't passed to workers.  Even if they
!              * were, the subplan might be using parallelism internally, and we
!              * can't support nested Gather nodes at present.  Finally, we
!              * don't have a good way of knowing whether the subplan involves
!              * any parallel-restricted operations.  It would be nice to relax
!              * this restriction some day, but it's going to take a fair amount
!              * of work.
               */
!             return;

          case RTE_JOIN:
              /* Shouldn't happen; we're only considering baserels here. */
--- 560,574 ----
          case RTE_SUBQUERY:

              /*
!              * If the subquery doesn't have anything parallel-restricted, we
!              * can consider parallel scans.  Note that this does not mean that
!              * all (or even any) of the paths produced for the subquery will
!              * actually be parallel-safe; but that's true for paths produced
!              * for regular tables, too.
               */
!             if (has_parallel_hazard((Node *) rte->subquery, false))
!                 return;
!             break;

          case RTE_JOIN:
              /* Shouldn't happen; we're only considering baserels here. */

pgsql-hackers by date:

Previous
From: Joe Conway
Date:
Subject: IsUnderPostmaster with shared_preload_libraries on Windows
Next
From: Tom Lane
Date:
Subject: Re: IsUnderPostmaster with shared_preload_libraries on Windows