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

Поиск
Список
Период
Сортировка
От Noah Misch
Тема Re: ERROR: ORDER/GROUP BY expression not found in targetlist
Дата
Msg-id 20160627024209.GC1329944@tornado.leadboat.com
обсуждение исходный текст
Ответ на Re: ERROR: ORDER/GROUP BY expression not found in targetlist  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Mon, Jun 13, 2016 at 05:27:13PM -0400, Robert Haas wrote:
> One problem that I've realized that is related to this is that the way
> that the consider_parallel flag is being set for upper rels is almost
> totally bogus, which I believe accounts for your complaint at PGCon
> that force_parallel_mode was not doing as much as it ought to do.
> When I originally wrote a lot of this logic, there were no upper rels,
> which led to this code:
> 
>         if (force_parallel_mode == FORCE_PARALLEL_OFF || !glob->parallelModeOK)
>         {
>                 glob->parallelModeNeeded = false;
>                 glob->wholePlanParallelSafe = false;    /* either
> false or don't care */
>         }
>         else
>         {
>                 glob->parallelModeNeeded = true;
>                 glob->wholePlanParallelSafe =
>                         !has_parallel_hazard((Node *) parse, false);
>         }
> 
> The main way that wholePlanParallelSafe is supposed to be cleared is
> in create_plan:
> 
>         /* Update parallel safety information if needed. */
>         if (!best_path->parallel_safe)
>                 root->glob->wholePlanParallelSafe = false;
> 
> However, at the time that code was written, it was impossible to rely
> entirely on the latter mechanism.  Since there were no upper rels and
> no paths for upper plan nodes, you could have the case where every
> path was parallel-safe but the whole plan was node.  Therefore the
> code shown above was needed to scan the whole darned plan for
> parallel-unsafe things.  Post-pathification, this whole thing is
> pretty bogus: upper rels mostly don't get consider_parallel set at
> all, which means plans involving upper rels get marked parallel-unsafe
> even if they are not, which means the wholePlanParallelSafe flag gets
> cleared in a bunch of cases where it shouldn't.  And on the flip side
> I think that the first chunk of code quoted above would be totally
> unnecessary if we were actually setting consider_parallel correctly on
> the upper rels.

[Action required within 72 hours.  This is a generic notification.]

The above-described topic is currently a PostgreSQL 9.6 open item ("set
consider_parallel correctly for upper rels").  Robert, since you committed the
patch believed to have created it, you own this open item.  If some other
commit is more relevant or if this does not belong as a 9.6 open item, please
let us know.  Otherwise, please observe the policy on open item ownership[1]
and send a status update within 72 hours of this message.  Include a date for
your subsequent status update.  Testers may discover new open items at any
time, and I want to plan to get them all fixed well in advance of shipping
9.6rc1.  Consequently, I will appreciate your efforts toward speedy
resolution.  Thanks.

[1] http://www.postgresql.org/message-id/20160527025039.GA447393@tornado.leadboat.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Noah Misch
Дата:
Сообщение: Re: ERROR: ORDER/GROUP BY expression not found in targetlist
Следующее
От: Noah Misch
Дата:
Сообщение: Re: primary_conninfo missing from pg_stat_wal_receiver